Показать сообщение отдельно
Старый 13.08.2008, 01:05   #1  
Blog bot is offline
Blog bot
Участник
 
25,475 / 846 (79) +++++++
Регистрация: 28.10.2006
msdynamicsax: Upgrading a database from Ax 4.0 SP1 to Ax 2009
Источник: http://msdynamicsax.wordpress.com/20...p1-to-ax-2009/
==============


The demo-data that comes with Ax 2009 is fine as long as you want to use US data, but for the rest of us who would like to demonstrate Ax 2009 in our language and with local customer names, items, ledger accounts and so on, we have the option of starting on scratch with an empty Ax 2009 database or upgrading a demo-database from 4.0.  

I descided on the last option as we are about to demonstrate Ax 2009 for a prospect and these are a couple of things I found that might be helpful (instead of reading the full upgrade guide you can find here: http://download.microsoft.com/downlo...gradeGuide.pdf). 

Note that the 4.0 solution did not have ANY modifications, so this is only an upgrade of the data.

First of all, the quick-steps should be fairly simple:

1. Backup the 4.0 database

2. Restore the backup to a new database

3. Install a new AOS-instance that points to the restored database

4. Start the AOS-service.

5. Start an Ax-client that points to the new AOS-instance and follow the upgrade checklist.

Now, what if life actually was this simple?

First of all, if the 4.0 database is taken from a different domain or you didn’t have access to that ax-solution, you have to do a little hack in the UserInfo-table from SQL Management Studio in order to be able to log in to the new solution. Change the administrator name, domain and alias to your network name and domain. You also have to change the sid in the UserInfo table. To find your sid in the new environment, open regedit and navigate to: HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider. Underneath this key, you kan find your sid. Copy the keyname and remove the path when pasting it into the sid-field in the UserTable in SQL Management Studio.

Also note that some of the locales has changed name from 4.0 to 2009. For Norwegian the localeId is now NB-NO instead of NO. I had to change the default language and helplanguage from NO to NB-NO in the UserTable as well.

You should now be able to log in to the new Ax solution and get the upgrade checklist.

Compile, license letter and so on should be fine. The really important steps are the pre-syncronization, syncronization and post-synchronization.

Before you start with any of these steps, make sure that your database is set up with simple recovery mode. This will save you a lot of time.

You should also run these scripts on your in SQL Management Studio: (the scripts are taken from the official Upgrade Guide).

–DIMENSIONCOLLECTION
UPDATE SQLDICTIONARY SET FIELDID=1 WHERE FIELDID=50002 AND TABLEID=2897;
UPDATE SQLDICTIONARY SET FIELDID=2 WHERE FIELDID=50005 AND TABLEID=2897;
UPDATE SQLDICTIONARY SET FIELDID=3 WHERE FIELDID=50007 AND TABLEID=2897;
UPDATE SQLDICTIONARY SET FIELDID=4 WHERE FIELDID=50008 AND TABLEID=2897;
–DIMENSIONHIERARCHYCOMBINATION
UPDATE SQLDICTIONARY SET FIELDID=1 WHERE FIELDID=50002 AND TABLEID=2898;
UPDATE SQLDICTIONARY SET FIELDID=2 WHERE FIELDID=50003 AND TABLEID=2898;
UPDATE SQLDICTIONARY SET FIELDID=3 WHERE FIELDID=50005 AND TABLEID=2898;
UPDATE SQLDICTIONARY SET FIELDID=4 WHERE FIELDID=50006 AND TABLEID=2898;
UPDATE SQLDICTIONARY SET FIELDID=5 WHERE FIELDID=50009 AND TABLEID=2898;
–DIMENSIONSETCOMBINATIONDUP2899
UPDATE SQLDICTIONARY SET FIELDID=1 WHERE FIELDID=50001 AND TABLEID=2899;
UPDATE SQLDICTIONARY SET FIELDID=2 WHERE FIELDID=50002 AND TABLEID=2899;
UPDATE SQLDICTIONARY SET FIELDID=3 WHERE FIELDID=50003 AND TABLEID=2899;
–DIMENSIONSETCOMBINATIONTEMP
UPDATE SQLDICTIONARY SET FIELDID=1 WHERE FIELDID=50001 AND TABLEID=2900;
UPDATE SQLDICTIONARY SET FIELDID=2 WHERE FIELDID=50002 AND TABLEID=2900;
UPDATE SQLDICTIONARY SET FIELDID=3 WHERE FIELDID=50003 AND TABLEID=2900;
UPDATE SQLDICTIONARY SET FIELDID=4 WHERE FIELDID=50004 AND TABLEID=2900;
UPDATE SQLDICTIONARY SET FIELDID=5 WHERE FIELDID=50005 AND TABLEID=2900;
UPDATE SQLDICTIONARY SET FIELDID=6 WHERE FIELDID=50006 AND TABLEID=2900;
–PROVISIONALHIERARCHY
UPDATE SQLDICTIONARY SET FIELDID=1 WHERE FIELDID=50001 AND TABLEID=2901;
UPDATE SQLDICTIONARY SET FIELDID=2 WHERE FIELDID=50002 AND TABLEID=2901;
UPDATE SQLDICTIONARY SET FIELDID=3 WHERE FIELDID=50007 AND TABLEID=2901;

The reason you should run these scripts are that a couple of fieldId’s for some tables have different values in the AOT than in the SQLDICTIONARY -table. This is not the case for all upgrades, but in some cases it is, and these scripts doesn’t do anything wrong in any case.

Another nice hint is to ALWAYS take a backup of the database before you start the post-synchronization step. It’s not a bad idea to take a backup before all of the synchronization steps, but before the post-synchronization should be mandatory.

The rest of this upgrade was straightforward.




Источник: http://msdynamicsax.wordpress.com/20...p1-to-ax-2009/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.