Nav developer's blog : Upgrade

Problems in transformation forms to pages using TransformationTools

gediminb — Mon, 14 Sep 2009 15:10:00 GMT

After Microsoft Dynamics NAV 2009 SP1 release more and more developers start using it and trying to adopt existing solutions for new 3tier environment.
Most workload comes from trying to adopt current forms to new object - pages.
Particularly transformation could be done by using TransformationTools (http://msdn.microsoft.com/en-us/library/dd338789.aspx), however it is not "best ever" and partners reporting problems and require to fix it...

But it isn't so easy...

This tool is delivered to us from dev team and it helps us to make transformation faster, but it is supplementary tool - we can use NAV without this tool and we can "convert " our solutions without it - do it manually.
So "big thanks" to dev team for this tool, however we can't expect that dev team will fix all problems in tool with the same priority as base products (Microsoft Dynamics NAV).

And we can't expect fixes for problems related to incorrect transformed statements - after transformation pages can't be compiled...
Problem is in tool simplicity: it searches for text and convert it to another text. Converting rules are described in file CodeRules.txt (http://msdn.microsoft.com/en-us/library/dd338843.aspx).
But simplicity is as strength as weakness of this tool - only text described in CodeRules.txt file will be converted, if there are any differences in text - transformation will be incorrect.
For example:
In form code we have statement:
CurrForm.Number.UPDATEFONTBOLD(Number);
Then after transformation on page will be created new variable NumberEmphasize
And statement will be converted to:
NumberEmphasize := Number;
It is because UPDATEFONTBOLD is not used in pages and must be removed.

So far so good.
Tranformation will be done correct for statements:
CurrForm.Number.UPDATEFONTBOLD(Number1=Number);
CurrForm.Number.UPDATEFONTBOLD(Number1>Number);
and etc. because transformation rules are described in CodeRules.txt

But transformation tool is looking for direct text fit to rules and will not transform text which is not described in Coderules.txt.
If code becomes little more complicated (not described the same syntax as CodeRules) - transformation tool capitulates.
For example next code will not be transformed:
CurrForm.Number.UPDATEFONTBOLD(Number1<Number);
CurrForm.Number.UPDATEFONTBOLD(Number1=xRec.Number);
CurrForm.Number.UPDATEFONTBOLD(xRec.Number1=Number);
CurrForm.Number.UPDATEFONTBOLD(Number1=Number2=Number3);
CurrForm.Number.UPDATEFONTBOLD(Number1=(Number+100));
...

Yes... We can make rules for these statements too (dev team delivered rules file), but we will never describe everything what could be written by happy-creative developpers around the world...
Maybe some rules could be never used? Who knows..?

I can collect all requirements for CodeRules.txt and periodically release new one (fixed). Do you want to order me do it, let me know in comment to current post :) ...

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

Gedas Busniauskas

Microsoft Lithuania
Microsoft Customer Service and Support (CSS) EMEA

Upgrading to Dynamics NAV 2009

jvukovic — Mon, 18 May 2009 17:10:00 GMT

Upgrade procedure to Dynamics NAV 2009 is not very different from upgrade procedures we had in previous versions, but some differences do apply, depending on what we want to achieve with the upgrade.

First scenario is executables only upgrade, which is the same as traditional executables upgrade in NAV. That means upgrading classic NAV client to NAV 2009 version by opening previous database versions with new client, and selecting yes when prompted to convert database, without any object changes or data transfer. Or alternatively, creating a new database with NAV 2009 client, and restoring a backup of customer's database.

This will, as before, upgrade the version of executables running NAV to 2009 version (builds 6.0 and higher) and create necessary system tables, but this will not automatically open up for using new NAV 2009 functionality (like RTC client or Web Services). Running the first scenario is a mandatory part of any upgrade scenario, just as it was in previous versions.

Beware of few issues that can rise from this scenario, see the link below for description.

http://blogs.msdn.com/nav_developer/archive/2009/05/08/upgrading-older-databases-to-nav-2009-runtime.aspx

Another scenario is doing an executable upgrade that would open up for using Web services, but would not include any object upgrade or data transfer.

This is where 3-tier scenario enters stage and a Dynamics NAV server should be set up and connected to the database (this is the normal installation/setup process of the service). Dynamics NAV Web service should also be installed, see Dynamics NAV documentation for installation and setup of different components.

http://msdn.microsoft.com/en-us/library/dd301130.aspx

To be able to use Web Services after doing an upgrade of executables and setting up a NST and Web service, one must also import and populate web service form (810) from a NAV 2009 client. This will open up for exposing codeunits (and also pages, but at this stage, pages are not yet present in database).

To further enable using RTC, one should also import tables 9050-9060, these are cue tables used in role centers of RTC. If you are creating and running custom Role Center pages, remember to create a record in each table by specifying any value as primary key (or follow code examples from standard Role Center pages that will insert a record if table is empty). A record in any of these tables will be automatically inserted when using standard NAV Role Page (based on that table).

In addition, reports should be 'transformed' to add RDLC layer and forms should be transformed to pages. You can also run reports with classic engine form RTC (that is run classic NAV report in RTC), in which case no object upgrade is necessary for reports. Note though, to run reports with classic engine on RTC client, each machine running RTC client (and classic reports) needs to have Classic client installed as well.

Furthermore, Role Center pages should be created or standard ones imported from NAV 2009 client (pages in range 9000-9020). Finally, PROFILE table (table 2000000072) should be populated with standard (or custom) profiles, and role center pages tied to these.

Last, but not least, you must make sure the existing code is modified to run in both scenarios (see MSDN documentation on code considerations for NAV 2009).

However, the job needed in this last scenario (specially transforming forms and reports) is not much different than using full database upgrade . In full upgrade version, objects in standard and custom version of NAV (version we are upgrading) would be merged with standard NAV 2009 objects to create custom NAV 2009 database. Note, all forms in standard NAV 2009 version are transformed to pages, so it is advisable to run Form transformation to create pages, once forms are merged to NAV 2009 object version. Also, one should 'upgrade' reports to add RDLC layer, once custom reports are merged to NAV 2009 version.

No data transfer would occur from W1 5.0 to W1 NAV 2009 version, as there are no changes to table structure from 5.0 version. Upgrading from earlier version would still imply data transfer using Upgrade Toolkit.

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

Best regards,

Jasminka Vukovic

Microsoft Dynamics NO

Microsoft Customer Service and Support (CSS) EMEA

Beware the SQL Index property on NAV 5.0 SP1

lalake — Fri, 10 Apr 2009 16:16:00 GMT

The discussion of the changes starting with Microsoft Dynamics NAV version 5 regarding the use of Dynamic cursors has already been addressed in the article titled "Cursor Types" on the SE Blog - http://blogs.msdn.com/microsoft_dynamics_nav_sustained_engineering/

However, we are seeing more and more cases where the use of the SQL Index property in NAV 5.0 SP1 is causing performance issues, so the purpose of this blog is to explain in more detail from an application perspective how this property can affect performance.

From version 5.0 we are using Dynamic cursors, which means that SQL server will tend to choose an index that fits the ORDER BY clause more than the WHERE clause. This is not a problem as long as there is no conflict between the ORDER BY and the WHERE clause. This is where the SQL Index property comes in.

SQL server should be able to choose the optimal index IF we create an index which matches the ORDER BY or the filter/range perfectly. NAV constructs the ORDER BY based on the NAV Key specification not the SQL Index specification. If a SQL Index value is specified on the NAV key and the fields do not exactly match the fields and the order in which they were specified in the Key, then there could be a conflict between the ORDER BY and the WHERE clauses.

How does the issue present itself in the application? These are just a couple of examples we have seen of the impact the SQL Index specification can have on the application…

Poor performance on large tables like Ledger Entry tables, if a user selects Sort on the form and changes from the primary key to a secondary key which has a SQL Index specification.

Using the RunFormView and RunFormLink property of a form…If the RunFormView is set to a non-primary key, SQL might not choose the first key matching the RunFormView if that key has a SQL Index specification. Depending on the keys defined on the table, there may not be another adequate key available, so a suboptimal index may be used. The ORDER BY may no longer match the WHERE clause (RunFormLink), resulting in very poor performance loading the form.

Performance problems when SETCURRENTKEY/SETRANGE is used in code and the key specified has a SQL Index specification that does not match the key or the filters entered (WHERE clause).

************

We are seeing issues mainly with customers who have upgraded to 5.0 SP1 from 5.0, because there were values specified for SQL Index in many tables in the base product in 5.0. Some other customers on pre-5.0 versions might also have issues if someone has done performance tuning on their database. In earlier version of NAV, SQL Index was used to improve performance in certain scenarios.

The recommendation is that the use of the SQL Index specification should be limited to very specific situations where thorough testing shows performance improvement. In the vast majority of scenarios, SQL will make the correct choice of Index, so the SQL Index specification is not needed and can actually cause poor performance.

For more information on identifying these problematic queries, please see the SE Blog post mentioned at the top of this article.

Laura K. Lake

Microsoft Dynamics NA

Microsoft Customer Service and Support (CSS) North America

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

Upgrading Application Objects - Tips

lalake — Tue, 06 Jan 2009 16:01:00 GMT

Some partners use the Merge tool in the NAV Developer Toolkit to attempt to merge the FULL set of objects from the old and new versions. This is not necessary and often will cause more problems than it is worth.

For the purpose of discussion, let's say that you are upgrading a database from version 3.70 to 5.0 SP1.

One common error that occurs is something like this...

Your program license does not permit you to delete the IC Partner Code field in the table.

The IC Partner Code field is a field that did not exist in 3.70 but has been added to the 5.0 SP1 database. Most often what we find is that partners are mistakenly trying to import the merged objects into the Customer's database when they receive errors like this. The new fields for 5.0 SP1 do not exist in the customer's database. You will not be able to import the merged text file that you created from the Developer's Toolkit into your customer's database. You must first import the text file into a base Cronus 5.0 SP1 database. Once the import has completed successfully, you will then export all the objects from this database as an fob file, and then you will be able to import the fob into your customer's database.

These program license errors also occur if the object merge is not handled correctly. The main thing to keep in mind is that there will be fields that existed in 3.70 that do not exist in 5.0 SP1 and new fields in 5.0 SP1 that did not exist in 3.70. A partner license will not permit you to delete or create fields in the NAV reserved range. However, this SHOULD NOT be a problem if the object merge is done correctly. Keep in mind that if there have been NO modifications to an object, then there is no need to import a merged version of that object into 5.0 SP1. Any data from 3.70 that needs to be converted will be handled during the data conversion part of the upgrade process. When you run step 1 of the upgrade toolkit, the data that needs to be converted will be moved over to temporary tables and then converted during step 2.

Concentrate on your modified objects. If you are going to use the NDT to perform the merge, try working with only the modified set of objects rather than trying to merge every object in the database. As a matter of fact, it will often be faster to manually re-enter your modifications in the base 5.0 SP1 database than to try to track down all of the errors that can occur with the merge. One option is to use a text compare tool to compare the base 3.70 unmodified table to your modified one, then manually copy and paste your modifications into 5.0SP1. The NDT function Compare Two Versions works well for this purpose. TIP: Make sure before you do a text compare that the language layers in the "Old Base Version" match the "Current Custom Version". This will prevent having nearly every object show differences in the Compare Tool due to captions...

Open a clean Cronus database for your Old Base Version.
Go to Tools/Object Designer.
Go to Tools/Language Module/Export
Select a file name on your computer for the export in case you should need it at some time in the future.
Select one of the languages that you do not want and then be sure to click the Delete Language text box. Select OK.
Repeat for each of the languages that you do not need.

Another thing to keep in mind when using the Merge Tool in the Developer Toolkit is that you usually cannot just Accept All Changes with a set of customized objects, because there are almost always conflicts in code that must be resolved manually. Many developers prefer to use the Compare tool in the toolkit and then copy and paste the changes manually into the new version. Compare and Merge is a tool for developers to use as they see fit, but it is not flawless, so you should always check the suggested changes and resolve any conflicts manually.

Laura K. Lake

Microsoft Dynamics NA

Microsoft Customer Service and Support (CSS) North America

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

Error - Cannot create more than one clustered index on table

lalake — Fri, 17 Oct 2008 22:19:00 GMT

This post describes one scenario in which this error occurs. There may be others.

In the late 4.0 versions of the NAV executables, all tables in NAV had a clustered index created on SQL for the primary key (Index 0).
However, the table objects in 4.0 versions did not have the Clustered property set on any of the keys.
It was also possible on 4.0 to toggle that property (on/off) and NAV would allow you to leave the table with none of the keys flagged as clustered, but the primary index on SQL remained clustered.

In the 5.0 versions, this behavior has changed. It is no longer possible to modify a table object to turn off the Clustered property on all keys. If you do this, save and compile the table, and then go back into designer and view keys, you will see that the 5.0 (and SP1) client has automatically turned on the Clustered property on the primary key. It is not possible in 5.0 to create a table with no clustered index.

So, consider a scenario where you have a 4.0 database that has been converted to 5.0 SP1 executables. This is usually done one of two ways...

1) Open the 4.0 database with the 5.0 SP1 executable and click Ok to convert
2) Create a new database with the 5.0 SP1 executable and restore the 4.0 database backup using the NAV Client.

With 5.0 SP1, using either of these two methods, the Clustered property on the 4.0 object's primary key is automatically flagged.

If for any reason a 4.0 table object is later imported into the converted database, you end up with a situation where the clustered index remains on SQL, but the table object no longer has the Clustered property flagged. This doesn't cause any immediate problem, but let's say you later want to do a full object upgrade to 5.0 SP1 objects. In step 8 of the Upgrade Quickguide, you are instructed to import the new customized objects created in the compare and merge process. Some of the 5.0 SP1 table objects, for example Sales Header, have had the clustered index changed to a secondary key. When these tables are imported into the database, NAV will not drop the primary clustered index but will try to create the secondary clustered index, triggering the above error.

The workaround for this issue is to go into the table object in design mode and flag the primary key as clustered, then try importing the 5.0 SP1 table object again. Because the Clustered property is set, NAV will drop and recreate the primary key (index on SQL) before creating the secondary clustered index.

Laura K. Lake

Microsoft Dynamics NA

Microsoft Customer Service and Support (CSS) North America

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.