Sunday, 3 May 2009

Differences between RTC and Classic Client

Probably the biggest headache when developing for Microsoft Dynamics NAV 2009 is when you find different behaviour between the same code executing in different clients. I have experienced this twice so far and both times took a little sorting out.

The first issue was when I tried to import a FOB file that referenced a DLL. The DLL had not been registered on the machine on which I made the import and, prior to NAV 2009, this was not a problem. If you did not have a particular DLL, you would not receive an error until you tried to access the DLL at run time or tried to recompile the object. The FOB files are shipped pre-compiled so there was no need to have the DLL registered on machine just to be able to import the objects.

What I found in NAV 2009 was that although the object imported without errors, an additional message reported that there were problems with one of the objects (can't remember the exact message) but basically what was happening was that once the objects had been imported, the system was attempting to create the C# code to be used by the Service Tier. Since the DLL being referenced could not be found, the C# code did not get created. As a result, when a part of the system tried to access some code in the Codeunit, a run time error occurred – but only on the RoleTailored client (since it relies upon the C# version of the code) the Classic client worked fine. As a solution, we made a point of ensuring that any DLLs required by the system were registered on a computer that was to be used for importing FOBs.

The second problem I came across was as a result of a slight difference in the handling of Option type fields. In the Classic client, if you were to delete the contents of an option field on a form (thus making it an empty string), the system would insert the first option value. Often the first option value is a single space. If you were to do the same on the RoleTailored client, you would get an error message telling you that blank is not a valid option and you would be reminded what the valid options were. This can be quite confusing and you need to remember to type a single space in order to "blank" the field. I've learnt to live with this, but at the end of the week I discovered that this problem can be quite confusing when you hit it from code. One of the programming samples in our book that we provided for download was the ability to use the Data Migration tool to import Dimensions as well data. This has proved quite useful, but I found that when I was extending the tool to work with Document Dimensions (so I could import documents and not just master data) was getting a strange error that I did not get in the classic client. The problem was that I had some code that was trying to pull an option value from an XML document and it was getting an empty string, since the node could not be found. You can probably guess where this is going. The evaluation of the empty string resulted in perfect execution in the classic client but a run time error in the RoleTailored client telling me that the option was not valid. Since this problem only occurred on the RoleTailored client, I was forced to try out the debugging on the service tier (I followed the instruction Vjeko wrote in our book) and it helped me to track down exactly what was going on. It was then fairly straight forward to only evaluate the field value if the text from the XML node actually contained a value. I quite enjoyed debugging in Visual Studio. It was nice to have a debugger that allowed me to step into, over and out of code, as well as being reliable and predictable.

6 comments:

Anonymous said...

Hello

Did you report this bug to MS?

Gaspode said...

Hi there Mr. Anonymous. I figured that Microsoft must read my blog, but just in case they don't I let the product team know about this little feature.

Anonymous said...

I have a few part question:
1. So can you license ALL the NAV source code? Or do they hold back the business logic portion of it?
2. Do you know if all the code will be ported away from C/AL?
3. Do you get the source automatically or is it a steep premium?
Thank You

Gaspode said...

>>1. So can you license ALL the NAV source code? Or do they hold back the business logic portion of it?<<

You get access to all of the source code that is written in C/AL.

>>2. Do you know if all the code will be ported away from C/AL?<<

This has not been decided - or if it has been decided, it has not been made public.

>>3. Do you get the source automatically or is it a steep premium?<<

No you get the source code automatically. You do need to buy particular granules to be able to modify the objects.

Anonymous said...

Interesting. Our current ERP vendor is trying to withhold the business logic source from us. We licensed with them over ten years ago and now this. I've had a demo on NAV 2009 and was duly impressed.

Gaspode said...

The really great thing is that the C/AL source code is stored inside your database alongside your data. Your partner can access and modify these objects and deliver the objects to you. Should you fall out with your partner, you can go to another partner with your database and they will be able to carry on with your system. There is a method of hiding the source code in objects that some developers of add-ons use but this is not the normal practice and if you did decide NAV was for you, you could make it a contractual term that source code will not be removed from custom development.