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

What exactly does COUNT count?

Lohndorf — Thu, 08 May 2008 12:08:00 GMT

The command COUNT is pretty simple. But on the SQL option there are a number of different ways to count records, and each can give a different result. This is how the different ways of counting works in NAV on SQL:

There are two commands you can use: COUNT or COUNTAPPROX. As the name suggests, COUNTAPPROX is only designed to give an approximate count. But this does not necessarily mean that COUN is exact (I will come back to this later).

COUNTAPPROX:
This command doesn't actually count anything. It only asks SQL Server to make a query plan for a SELECT statement. Then it reads the estimated number of records from the query plan. This is how COUNTAPPROX looks in a profiler trace:

SET SHOWPLAN_ALL ON

SELECT * FROM "CRONUS International Ltd_$Standard Text" WITH (READUNCOMMITTED)

SET SHOWPLAN_ALL OFF

It is the same as if you click on Query -> "Display Estimated Execution Plan (Ctrl+L)" in SQL Server Management Studio, instead of running a query normally (Ctrl+E / F5). This tells SQL Server to only compile a query plan, but not actually run the query. The query plan will contain "estimated number of rows", which in turn is based on SQL Server statistics. This is the number that COUNTAPPROX returns.

COUNT:

COUNT works differently, depending on whether there is a filter on the table or not. Without a filter it can just go to Table-Information, and get the number of records from there. This is quicker than going to the actual table and count every record. On the SQL Side, it means counting the number of rows from the sysindexes table, like this:

SELECT SUM(rows), SUM(reserved) FROM [dbo].[sysindexes]

But sysindexes is not always up to date! Only just after having updated statistics, can you rely on the numbers in this table. So COUNT, without a filter, will not always give you the correct number.

If you have a filter, for example:

Cust.SETRANGE("Currency Code",'EUR');

i := Cust.COUNT;

Then the method of just looking up table-information doesn't work. So NAV has to count the records the hard way. In this case we finally get an actual COUNT SQL command:

SELECT COUNT(*) FROM "CRONUS International Ltd_$Customer"

But even this method of counting is still not necessarily accurate, because it reads uncommitted data. If you run the following code from another client, and leave the CONFIRM-dialog:

OnRun()
Cust.INSERT(TRUE);
Cust."Currency Code" := 'EUR';
Cust.MODIFY;

IF NOT CONFIRM('Continue?') THEN;

ERROR('Transaction rollback.');

Then, the COUNT above will include a record which never existed / was never committed.

The only way to get an exact count, is by applying a lock. For example:

Cust.LOCKTABLE;

i := Cust.COUNT;

This will give you an exact count, whether you have a filter or not. On the SQL side it will look like this:

SELECT COUNT(*) FROM "CRONUS International Ltd_$Customer" WITH (UPDLOCK)

Because of the UPDLOCK it only counts committed records. And because of the lock, NAV knows not to just look up the number of records from table information, but to run a SELECT COUNT on SQL Server.

Lars Lohndorf-Larsen

Microsoft Dynamics UK

Microsoft Customer Service and Support (CSS) EMEA

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

Nav developer's blog : C/AL

Problems in transformation forms to pages using TransformationTools

What exactly does COUNT count?