Over on the net you can find tips here and there on how to use a database from a live production environment and set it up as a database for a test or development environment.
A small detail that doesn't always get the right attention in such procedures is the cache file of Ax. I had a post about this earlier on in my blog. What it comes down to is that the filename of the cache file of the Ax client is derived from the GUID in the table SysSqmSettings.
If you simply copy the database from live to development or test, the GUID in this table is copied as well. If an Ax client connects to your AOS, it will use this value for deciding on the cache file. Now if you have multiple databases having the same GUID in this table, you get multiple different Ax instances linked to the same cache file. So one cache file for different environments. Needless to say this will give you strange or unexpected behaviour when running the Ax client.
So it always is a good idea to reset the GUID in table SysSqmSettings after the restore of your live production database into some test or development environment.
Wednesday, February 9, 2011
Subscribe to:
Post Comments (Atom)
And if you need a new Guid, you might just wanna visit this site:
ReplyDeletehttp://www.newguid.net/Guid_Generator.aspx
Quick and easy! :D
Hi Skaue,
ReplyDeleteThanx for the reaction!
You know you can create a new GUID in Ax with Winapi::createGUID() as well? (see http://dynamics-ax-live.blogspot.com/2010/03/how-to-create-guid-in-ax.html)
And for the table SysSqmSettings it is sufficient to replace the GUID with an all-zero GUID. The AOS will at startup generate a new GUID in that case :-)