There is another easy method. :-)
Start by creating a new database, an empty database. I'm giving it around 2GB of space in my example.
Set the recovery mode to Simple. You don't need point-in-time recovery for this database.
Then run the PowerShell command Initialize-AXModelstore on the database.
Observe the database now has the elements required for a modelstore.
Make sure you add the necessary users with proper access, so they can use the new Baseline database.
Finally, head over to the AOS Server Configuration and choose the Baseline database.
That is it. :-)
Tommy have you ever used the baseline db to identify changes a var or isv made to their model? I re-enabled the baseline db as per your instructions. Then I imported an updated model from an isv into the baseline db with powershell. From in Ax I can't actually see any changes. Compare doesnt show an "old isv" option. and the upgrade tools see nothing. I even tried openeing up utilidelementsold - empty. I changed the views in sql for the *old queries to point to my baseline db but still nothing in ax.
ReplyDeleteSo in short: is it possible to use the baseline DB to see what changes a var/isv have made to their model between releases?
Nevermind I found my problem, Ax didn't see the baseline DB because the server config was wrong. We changed the database servers a while back. On the config application you can change what server your database is on. But if you save the config to file you will see that the baseline database has its own server property. And on my config that still pointed to the old server.
ReplyDeleteSo much time wasted, when in doubt - look at the config file and don't trust the front end app :/
This is why I normally lurk instead of post, give it a bit of time and you find the answer yourself.
Hehe... I was actually planning on testing this out myself. I haven't yet fully tested the use of Baseline. I once tried to fill it with models and I started to get all sorts of errors, so I spent my energy elsewhere. I've been planning to look more closer into it, because the "old" concept is a very strong one when you need to merge code within AX. ;-)
DeleteOk so, using Baseline to install updates from SYP/ISV/VAR is actually very good. Not sure why I didn't use this before. Especially when ms sends us a Hotfix that is the size of a CU.
DeleteBefore I install anything I take a database backup, and instead of initialising the model store like you outlined I instead restore my backup over my (new/old/variable) baseline. Development environments don't have much data anyway.
Now I run the import into my development database, layer by layer go into Tools- Code Upgrade - Detect upgrade conflicts (you should run a full compile before I think). That will catch most problems, you will still struggle with SSRS reports changed underneath you. And you still can't be sure all is well before a full xpp compile to catch method parameter changes. But overall - it helps you catch things quickly.
(Tip on reports - if you decide you don't want to upgrade it: On the DP/Controller classes right click - add ins - open in new window - open old layer, you can xpo this and import it back to overlayer upgrade changes you don't want)
I also make private projects with for example SYP/ISV intersections for spot checking. Try it on the next big hotfix or partner update you get.
Dude, lol... you should blog about it instead hide it in a comment here. ;-)
DeletePerhaps I will blog about it. It makes perfect sense to do what you just describe, and I will try it myself.
Thanks for sharing!