Through one of my German colleagues I stumbled over the Enable for Microsoft Dynamics NAV Server feature. One I hadn’t be aware of it before.
We were discussing the upgrade of a solution to RTC and how we might use the warning messages thrown by the CSIDE compiler in the Error List window as a means in assessing the effort needed for this job.
“Be sure to have this feature enabled otherwise the warnings will not be thrown”, he said. “OK”, I said, “so aren’t these messages thrown on a proprietary database server?” “Probably not”, he answered. As the solution is humongous, on NAV 2009 Classic, we weren’t just going to tick the check box and see what would happen. So I suggested to do some research and find as much as possible info.
First I searched on the various forums and blogs for Enable for Microsoft Dynamics NAV Server. Did get only one hit; on the NAV Team Blog: What is the “Enable for Microsoft Dynamics NAV Server” option? Looked promising but appeared to be not very helpful (see my comment attached to the post). To select “this option […] if you are deploying the RoleTailored client” had already come to mind through the self-explanatory description of the check box. [^o)]
I wanted to know what exactly is triggered/installed/updated/… by selecting this option.
Thus I continued my search.
Error List
First I had a look at the CSIDE on the proprietary database server and what the Error List would show me. I compiled a number of objects that clearly did have code “obsolete for Microsoft Dynamics NAV Server”, as many of these RTC warnings tell you. Result: only errors were listed:
As I obviously could not find the Enable for Microsoft Dynamics NAV Server check box, I now turned to a SQL Server setup. I.e. created a new database without the Enable for Microsoft Dynamics NAV Server checked, imported the application objects and compile them. Result: again only errors listed.
So, yes indeed, I turned on the Enable for Microsoft Dynamics NAV Server feature to recompile the objects and see. Aha, turning on the features triggers the system to process all application objects:
We guessed it was recompiling them which was confirmed by the comment of MSFT Dean McCrae on this mibuso post that actually addresses another aspect of the Enable for Microsoft Dynamics NAV Server feature (see below).
OK, once the objects were processed I did the recompile. Result: errors AND warnings were listed:
[Y]
Notes
- I did hide a couple of the columns in the Error List window to make the data ‘anonymous’
- If you create a new SQL Server database by means of a NAV classic client Enable for Microsoft Dynamics NAV Server is checked by default
- After turning of the Enable for Microsoft Dynamics NAV Server feature a recompile did only show errors in the Error List window
- BTW: also not much info available on the Error List window; the only info I found was this blog post by Mark Brummel and this tiny subject in the Microsoft Dynamics NAV 2009 Developer and IT Pro Documentation.
Importing .fob
As already mentioned above when importing a .fob file with objects not yet compiled on/for a NAV database that is Enable for Microsoft Dynamics NAV Server a (new) message will appear telling you that the objects will be recompiled and asking you whether you want to continue. If you do continue, as said, all objects will be processed (i.e. recompiled) to create the C# code needed for the 3-tier setup. Potentially you will have a number of objects that will not compile. Typically objects that contain automation, OCX or .NET references that are not present/registered on your machine. However if your .fob file was created on a database enabled for Microsoft Dynamics NAV Server, it does already contain the C# code. Nevertheless this is no guarantee that the objects will not be recompiled. Only when the version of the two databases (i.e. development and the deployment databases) are the same the objects will not be recompiled. In other case it probably will be recompiled.
Note
To minimize the number of objects that will not (re)compile during the deployment of a .fob file concentrate your references to automation, OCX and .NETin a restricted number of objects. And preferably do not put these references in table objects so that your table definitions always compile so that your data model is working OK.
OK, my findings so far that I wanted to share with you. If you have info to add, go ahead below.
And of course: thanx, Stefan. [B]