You’re offline. This is a read only version of the page.
Hello:
You can reference my other posting, where I mention that my test GP 2013 R2 upgrade is failing for one out of sixteen databases, simply because a handful of fixed assets tables refuse to upgrade from GP 2010.
Here's the SQL help that I need.
I have backed up the data in those fixed assets tables into "backup" tables.
I can drop these fixed assets tables. And, I can recreate the tables, based on scripting that I created from other fixed assets tables in corresponding databases that successfully upgraded.
But, I cannot copy that data from the backup tables into these recreated GP 2013 tables because the GP 2013 tables have more columns in them than the GP 2010 tables have.
For example, the FA15000 table in GP 2010 has 11 columns, while the corresponding GP 2013 version of this table has 21 columns.
So, how do I copy the data from these backup tables into these new tables, so that GP Utilities will proceed with the upgrade?
Any ideas would be very much appreciated! If I don't hurry along with this test upgrade, I'm going to get behind schedule.
Thanks!
John
*This post is locked for comments
First, the following script needs to be run prior to the upgrade of the troubled database: DELETE DU000030.
Then, backups of the fixed assets tables need to be made. Next, create scripts that will be used to recreate these four GP 2010 tables. Afterward, drop these tables. Run the scripts, next, to recreate the GP 2010 tables. Continuing, restore the data from the backed up tables into the "new" GP 2010 tables. Finally, run GP Utilties and all will be well.
Hi Tom:
Actually, I ended up opening a support case with Microsoft. They gave me the remedy, which I'm going to document in my other posting.
Thanks, for your help!
John
Copying data table by table sounds a bit frightening especially as a work around for an upgrade.
What version of GP 2010 were you upgrading from? SP1, SP2 .... etc.. My guess is that the FA module PROD 309 for that particular company did not have the same version build # as all the other companies that upgraded successfully.
Do you have a backup of the old Dynamics DB before your upgrade? I would restore it to a local instance, even your own computer would be fine, and then investigate the DB_Upgrade and DU000020 tables and see if the db_verBuild for PRODID 309 is at a different build # or even the db_verMajor is a different version then all the other companies. My guess is that this why it's failing to upgrade.
I've had this type of issue come up before when restoring a backup of an older version into an upgraded environment because the tables from the backup are a different version than what Dynamics thinks it is which can throw all sorts of error during an upgrade.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,219
Super User 2024 Season 2
#2
Martin Dráb
230,056
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (