Because SP1 for Microsoft Dynamics NAV 2009 was released, I tried to create short demo of the new functionality, which allows developers to create tests for their code. Official documentation for this part of NAV 2009 SP1 could be found here.
How it works
You have new property on codeunit –Subtype – which could be “Normal,Test,TestRunner”.
Normal – you know it…
- Test – this codeunit have functions, which are testing the functionality, this is the main codeunit doing the testing
- TestRunner – this is codeunit which runs the test codeunits and e.g. collecting the results. Because you can run all tests by this one codeunit, it is not problem to run the tests e.g. in NAS or through webservices.
If you use Test subtype, you can use new property on each function in the codeunit – FunctionType – which could be
- Normal – again you know it…
- Test – this is the function which tests the functionality
- MessageHandler – handles cases, when you expect that some message will be displayed
- ConfirmHandler – handler for Confirm dialog, in which you can simulate the answer by user (yes,no)
- StrMnuHandler – same like ConfirmHandler but for String menu dialogs
- FormHandler – you can handle displayed form which you expect
- ModalFormHandler – same for modal form, you can simulate the result (Yes, No, Ok, Cancel, LookupOK, LookupCancel etc.)
- ReportHandler – handling reports which are runned by the tested function
Using the handlers could be complex task, how to create them is described here.
Each test function could have assigned one or more handlers, and if the handler is not used during the testing, it leads to test Failed result (it means you are expecting something but it didn’t happened).
In testing function you can use new keyword ASSERTERROR before some command to say that you are expecting error in the command or block of commands. After that you can test if correct error was raised by testing GETLASTERRORTEXT. If there is wrong error text, you can call ERROR and the test function will have result Fail, else it will be Success.
TestRunner codeunit could have two functions – OnBeforeTestRun and OnAfterTestRun – which could e.g. store the date and time of start of some test function, result of the test etc. More info is here.
Short Demo
1st Step – something to test
Because creating the tests is not easy task, best is to test only the base functions you are using. I cannot imagine to create test for testing all aspects of posting codeunit or something like that.
We will start by creating some function which we will test. I have created one codeunit with one function with one parameter of type boolean and result of type boolean. Logic is this:
If parameter is True, Confirm is displayed and if user select Yes, function return true. If User select No, function display Error with text ‘Canceled’.
If parameter is False, function return False.
The function looks like this:
PROCEDURE TestedFunction@1000000001(Parameter@1000000000 : Boolean) : Boolean;
BEGIN
IF Parameter THEN BEGIN
IF CONFIRM(’My Confirm’,TRUE) THEN
EXIT(TRUE)
ELSE
ERROR(’Canceled’);
END ELSE
EXIT(FALSE);
END;
You can see that I have used hardcoded texts. Please, take it as something, which will not happen in real development, I have used it to have as simple example as possible.
2nd Step – Testing codeunit
Ok, now we will create the test for this function. We want to test all three paths – Parameter = true, Answer = Yes; Parameter = true; Answer = No; Parameter = False. It means we will use three test functions:
- TestMyFunctionTrueYes
- TestMyFunctionTrueNo
- TestMyFunctionFalse
All three functions are of type ”Test”, whole codeunit is of type “Test”. There are no parameters or return datatype for these functions.
There is the code for these functions:
[Test]
[HandlerFunctions(ConfirmHandlerYes)]
PROCEDURE TestMyFunctionTrueYes@1000000000();
VAR
TestedFunction@1000000000 : Codeunit 50010;
BEGIN
IF NOT TestedFunction.TestedFunction(TRUE) THEN
ERROR(’Wrong Answer’);
END;
[Test]
[HandlerFunctions(ConfirmHandlerNo)]
PROCEDURE TestMyFunctionTrueNo@1000000001();
VAR
TestedFunction@1000000000 : Codeunit 50010;
BEGIN
ASSERTERROR TestedFunction.TestedFunction(TRUE);
IF GETLASTERRORTEXT <> ‘Canceled’ THEN
ERROR(’Unexpected error: %1′, GETLASTERRORTEXT);
END;
[Test]
PROCEDURE TestMyFunctionFalse@1000000006();
VAR
TestedFunction@1000000003 : Codeunit 50010;
ErrorText@1000000002 : TextConst ‘ENU=The update has been interrupted to respect the warning.’;
BEGIN
IF TestedFunction.TestedFunction(FALSE) THEN
ERROR(’Wrong answer’);
END;
Again, I have used hardcoded texts, do not use them in your real development!
You can see, that first two functions have assigned Handler Function. One is simulating the answer Yes, one answer No. In second function we are expecting error, thus ASSERTERROR was used. Than we test if the correct error was triggered.
Now how the handlers looks like:
[ConfirmHandler]
PROCEDURE ConfirmHandlerYes@1000000002(Question@1000000000 : Text[1024];VAR Answer@1000000001 : Boolean);
BEGIN
IF Question <> ‘My Confirm’ THEN
ERROR(’Unknown Confirm text: %1′,Question);
Answer := TRUE;
END;
[ConfirmHandler]
PROCEDURE ConfirmHandlerNo@1000000003(Question@1000000001 : Text[1024];VAR Answer@1000000000 : Boolean);
BEGIN
IF Question <> ‘My Confirm’ THEN
ERROR(’Unknown Confirm text: %1′,Question);
Answer := FALSE;
END;
Both are ConfirmHandlers, we are handling the confirm dialog. We are testing that correct confirm dialog was displayed.
Now we have the testing codeunit. Ok, what’s next?
3rd Step – Test runner codeunit
Now we just prepare codeunit which will run this test. This codeunit could be more complex than in our example, e.g. it could run tests based on some setup table, where you can select which tests to run etc. I will give you example of both functions which could be used in this codeunit.
Start with creating new codeunit, select the Test runner subtype. In the OnRun trigger add this line:
CODEUNIT.RUN(CODEUNIT::”Test codeunit”);
That’s all if you want only to test the functionality. If you want to do something more, e.g. log the results, you can add these two functions:
VAR
Before@1000000000 : DateTime;
TestResult@1000000001 : Record 50000;
PROCEDURE OnBeforeTestRun@1000000002(CodeunitID@1000000000 : Integer;CodeunitName@1000000001 : Text[30];FunctionName@1000000002 : Text[30]) : Boolean;
BEGIN
Before := CURRENTDATETIME;
EXIT(TRUE);
END;
PROCEDURE OnAfterTestRun@1000000003(CodeunitID@1000000002 : Integer;CodeunitName@1000000001 : Text[30];FunctionName@1000000000 : Text[30];Success@1000000003 : Boolean);
BEGIN
TestResult.INIT;
TestResult.”Entry No.” := 0;
TestResult.”Codeunit ID” := CodeunitID;
TestResult.”Codeunit Name” := CodeunitName;
TestResult.”Function Name” := FunctionName;
TestResult.”Test Start” := Before;
TestResult.”Test End” := CURRENTDATETIME;
IF Success THEN
TestResult.Status := TestResult.Status::Success
ELSE BEGIN
TestResult.Status := TestResult.Status::Failure;
TestResult.”Error Text” := GETLASTERRORTEXT;
END;
TestResult.INSERT(TRUE);
END;
TestResult global variable is using new table I have created. You can create it easily, just look at the code, it is clear which datatype is used and how to name the fields. The PK of the table is AutoIncrement=Yes.
4th Step – Run the test
Ok, what to say – Run the Test Runner…
Now you can play with the tested function and e.g. modify the logic to return wrong error or wrong result. All will lead to Failed test.
Conclusion
Ok, now you have imagination how it works. But, are we able to use it to test some complex functionality? That’s the question. I do not know. I am a beginner in Test Driven Development, I can imagine using it for some basic functions, may be that when we will test each function, it will mean that complex functionality is tested too, but I cannot imagine that Customer will want to pay for the time we will spend by creating the test functions. Or, may be he will pay, if the result will be much less bugs which costs money too… What’s your opinion on this? Is it possible to create e.g.. Fully tested Addon? Biggest problem will be the GUI and functionality connected to the GUI, e.g. when I wanted to test the Availability warning, if it is correctly displayed, I was not able to do it, because the warning isconditioned by CurrFieldNo and I am not able to simulate it (the warning is not displayed when the functionality is called from code).
September 2nd, 2009
Posted by
kine |
Dynamics NAV, NAV 2009 |
no comments
I made decision and the source code for my application is now public. You can freely extend/update the code through GIT tools. The project is available on this address:
git://github.com/kine/NAV_NST_Management.git
I hope that this application will grow into superb tool for administering the NST services and may be not only the NSTs.
July 30th, 2009
Posted by
kine |
Dynamics NAV, NAV 2009 |
no comments
Hello all,
today I am glad that I can introduce you my new application, which is focused on management of NAV 2009 service tier and WebService. In last few days I learned much about C# and managing services, reading and modifying XML files etc. Result is the application named “NAV 2009 NST Management”.
What you can do with this application?
- Start/Stop the NAV services
- Create new instances of the services
- Configure the services (change DB server, DB name, and enable/disable debugging on them)
- Remove the services (excluding the default one)
- Do it all on remote machine (remote registry access required)
I hope that this application will help all of you who needs more instances of the services (developers etc.). The new instances are created with .NET port sharing, it means running all on same default port (you need to run the service for port sharing manually, it is disabled by default). They differs only by instance name. All is based on the example from Freddy’s blog (BIG thanks to Freddy). Instances are created as running under NETWORK Services account. If needed, may be setting the account will be possible in some next version ;-).
Enjoy the app, thanks for any feedback.
NAV 2009 NST Management
January 25th, 2009
Posted by
kine |
Dynamics NAV, NAV 2009 |
no comments
Today I prepared some stats about network traffic in NAV 2009 RTC client. You can compare the results with C/Side client (classic client).
Measuring: for measuring I have used the Microsoft Network Monitor for catching the NAV communication between client and DB Server/Service tier. Than I create sum of Frame Length, TCP Payload length and count of frames for the communication for each process. The results are not exact, because there are many things I didn’t take into account (cold/warm buffers, transfers of objects into classic client, used another order for measuring etc.). It means take the stats as example, how it can look like, but not as precise bandwidth measuring. Sizes are in Bytes.
Results:
|
Process
|
Frame total size (C/Side) |
Frame total size (RTC) |
Payload total size (C/Side) |
Payload total size (RTC) |
Frames count (C/Side) |
Frames count (RTC) |
WIN
|
Comment
|
|
Client start
|
475 944 |
301 859 |
435 237 |
282 113 |
753 |
364 |
RTC
|
Start of client (Role center with data on RTC, Navigation Pane only on Classic)
|
|
Order list
|
387 740 |
253 255 |
356 366 |
237 775 |
581 |
286 |
RTC
|
Opening list (different size of window, in Classic opening first card and F5 on card)
|
|
Open order card
|
318 292 |
160 012 |
291 508 |
149 500 |
496 |
194 |
RTC
|
Opening card
|
|
Nothing to post
|
265 980 |
22 346 |
243 510 |
20 075 |
416 |
41 |
RTC
|
Processing
|
|
Closing order card
|
17 387 |
28 724 |
5 777 |
26 840 |
215 |
34 |
C/Side
|
Closing form
|
|
Order confirmation preview
|
538 989 |
1 000 756 |
504 429 |
939 150 |
640 |
1 108 |
C/Side
|
Printing
|
|
Open departments page
|
N/A |
6 167 |
N/A |
5 669 |
N/A |
9 |
|
Only in RTC
|
|
Adj. cost - item entries
|
4 453 658 |
51 371 |
3 853 774 |
44 075 |
11 108 |
134 |
RTC
|
Processing only
|
|
Post cost to G/L
|
1 910 662 |
3 415 814 |
1 599 491 |
3 187 554 |
5 749 |
4 190 |
C/Side
|
Processing + printing
|
|
Add line on Sales Order (filled fields Item no., location, quantity, price)
|
1 742 217 |
402 336 |
1 605 192 |
375 788 |
2 536 |
487 |
RTC
|
Processing only
|
Conclusion:
Form the table you can see the effect of 3-tier system. When you are processing some data, RTC is much better, because no raw data are transfered. Classic client needs to read all data to process them. But problem for RTC are Reports. When you want to print something in RTC, the client need to transfer the Flat Table structure with all the data to process them in the Reporting System Client. And this table can be big. One page with order confirmation took 1MB of data. I do not want to see some 100page report… and I am not talking about bitmaps on the report (e.g. Company logo). But because printing is not critical operation in most cases in NAV, it is OK, because critical things like data processing are 90% of whole application. When you create sum for whole data transferred for both clients, classic client transferred around 10MB and RTC only 5.5MB. Still, RTC is much better with the transfers and this difference will be much bigger in real live when you are mostly posting and sometime printing. Another difference is the Frame count. RTC is sending much less frames but they are bigger. It can lead to change in performance too. But this is question for some Network specialist.
What is you opinion? Are you happy that I created this table? Was it helpful for you?
I am waiting for your comments…
Kamil (Kine)
October 9th, 2008
Posted by
kine |
Dynamics NAV, NAV 2009 |
no comments
Today I made some statistics about NAV 2009 CTP4 tables and compared the result with the stats for NAV 5.00SP1. There are the tables:
Tab 1) Field relations by type:
| Relation Type |
Count
(5.00SP1) |
Count
(NAV 2009) |
Difference |
| AVERAGE |
5 |
5 |
0% |
| COUNT |
109 |
193 |
+77% |
| EXIST |
135 |
135 |
0% |
| LOOKUP |
291 |
294 |
+1% |
| MAX |
9 |
9 |
0% |
| MIN |
14 |
14 |
0% |
| SUM |
415 |
415 |
0% |
| -SUM |
70 |
70 |
0% |
| TABLEREL |
5468 |
5497 |
<1% |
| -EXIST |
1 |
1 |
0% |
| Grand Total |
6517 |
6633 |
+1.7% |
You can notice, that the biggest difference is in COUNT flowfields. It is mainly because these new stacks in the new RoleTailored client.
Tab 2) Field data types:
| Data type |
Count
(5.00SP1) |
Count
(NAV 2009) |
Difference |
| Code |
6377 |
6425 |
48 |
| Decimal |
2984 |
3013 |
29 |
| Text |
2310 |
2314 |
4 |
| Integer |
1603 |
1674 |
71 |
| Boolean |
1452 |
1467 |
15 |
| Option |
1279 |
1288 |
9 |
| Date |
1025 |
1044 |
19 |
| Time |
127 |
129 |
2 |
| DateFormula |
101 |
101 |
0 |
| DateTime |
57 |
59 |
2 |
| BLOB |
48 |
53 |
5 |
| GUID |
17 |
19 |
2 |
| RecordID |
6 |
6 |
0 |
| Duration |
2 |
2 |
0 |
| TableFilter |
1 |
1 |
0 |
| BigInteger |
1 |
3 |
2 |
| Grand Total |
17390 |
17598 |
208 |
Tab 3) Field data types including length:
| Filed type and length |
Count
(5.00SP1) |
Count
(NAV 2009) |
Difference |
| Code10 |
3387 |
3413 |
26 |
| Decimal |
2984 |
3013 |
29 |
| Code20 |
2871 |
2889 |
18 |
| Integer |
1603 |
1674 |
71 |
| Boolean |
1452 |
1467 |
15 |
| Option |
1279 |
1288 |
9 |
| Date |
1025 |
1044 |
19 |
| Text50 |
973 |
974 |
1 |
| Text30 |
672 |
673 |
1 |
| Text80 |
253 |
254 |
1 |
| Text250 |
188 |
180 |
-8 |
| Time |
127 |
129 |
2 |
| DateFormula |
101 |
101 |
0 |
| Text20 |
87 |
83 |
-4 |
| DateTime |
57 |
59 |
2 |
| BLOB |
48 |
53 |
5 |
| Text10 |
39 |
39 |
0 |
| Code30 |
35 |
38 |
3 |
| Code3 |
21 |
21 |
0 |
| Text100 |
20 |
20 |
0 |
| Code250 |
19 |
20 |
1 |
| Code100 |
17 |
16 |
-1 |
| Code50 |
17 |
17 |
0 |
| GUID |
17 |
19 |
2 |
| Text65 |
16 |
21 |
5 |
| Text64 |
8 |
15 |
7 |
| Text38 |
7 |
6 |
-1 |
| RecordID224 |
6 |
6 |
0 |
| Text200 |
6 |
6 |
0 |
| Text249 |
6 |
3 |
-3 |
| Text5 |
6 |
6 |
0 |
| Code80 |
5 |
5 |
0 |
| Text119 |
4 |
8 |
4 |
| Text70 |
3 |
3 |
0 |
| Code130 |
2 |
1 |
-1 |
| Duration |
2 |
2 |
0 |
| Text150 |
2 |
2 |
0 |
| Text19 |
2 |
1 |
-1 |
| Text199 |
2 |
2 |
0 |
| Text90 |
2 |
2 |
0 |
| Text99 |
2 |
1 |
-1 |
| BigInteger |
1 |
3 |
2 |
| Code1 |
1 |
1 |
0 |
| Code2 |
1 |
1 |
0 |
| Code98 |
1 |
1 |
0 |
| TableFilter |
1 |
1 |
0 |
| Text118 |
1 |
1 |
0 |
| Text127 |
1 |
1 |
0 |
| Text131 |
1 |
1 |
0 |
| Text14 |
1 |
1 |
0 |
| Text149 |
1 |
1 |
0 |
| Text151 |
1 |
1 |
0 |
| Text220 |
1 |
1 |
0 |
| Text3 |
1 |
1 |
0 |
| Text31 |
1 |
1 |
0 |
| Text32 |
1 |
1 |
0 |
| Text63 |
1 |
1 |
0 |
| Text7 |
1 |
0 |
-1 |
| Code40 |
0 |
2 |
2 |
| Text128 |
0 |
2 |
2 |
| Text240 |
0 |
1 |
1 |
| Text4 |
0 |
1 |
1 |
| Grand Total |
17390 |
17598 |
208 |
Tab 4) Overall stats:
|
NAV 5.00SP1 |
NAV 2009 CTP4 |
| Tables |
918 |
944 (+26) |
| Fields |
17390 |
17598 (+208) |
| Fields per table (Avg) |
18,94 |
18,64 |
| Average count of relations per table |
7,099 |
7,026 |
| Percentage of fields referring other fields |
37,47% |
37,69% |
| Max fields in table |
176 (Tab 39 - Purchase Line)
175 (Tab 27 - Item) |
177
(Tab 39 - Purchase Line)
175 (Tab 27 - Item) |
| Max table relations per table (All) |
93 (Tab 18 - Customer) |
93 (Tab 18 - Customer) |
| Max table relations per table (Table Rel) |
66 (Tab 81 - Gen. Journal Line) |
66 (Tab 81 - Gen. Journal Line) |
| Max table relations per table (FlowFields) |
63 (Tab 18 - Customer) |
63 (Tab 18 - Customer) |
| Most referred table |
266 (Tab 349 - Dimension Value)
258 (Tab 308 - No. Series)
235 (Tab 15 - G/L Account) |
266 (Tab 349 - Dimension Value)
258 (Tab 308 - No. Series)
235 (Tab 15 - G/L Account) |
As you can see, there is no big increase of table count and field count. The change is mainly because the new functionality for RTC. There are new tables with flowfields for calculating counts of documents and other information.
September 24th, 2008
Posted by
kine |
Dynamics NAV, Uncategorized |
no comments
Today I made some statistics about NAV 5.00SP1 tables. I know that the stats have no purpose, but you can see on them how complex the system is. It can help to someone, who just want to know, how much is something used in standard etc. There are the tables:
Tab 1) Field relations by type:
|
Relation Type
|
Count
|
|
AVERAGE
|
5
|
|
COUNT
|
109
|
|
EXIST
|
135
|
|
LOOKUP
|
291
|
|
MAX
|
9
|
|
MIN
|
14
|
|
SUM
|
415
|
|
-SUM
|
70
|
|
TABLEREL
|
5468
|
|
-EXIST
|
1
|
|
Grand Total
|
6517
|
A you can see, there is 6517 relations between fields (TableRel, SUM, Lookup etc.) or tables (Exist, Count). Of course, most of them are table relations and SUM flowfields.
Tab 2) Field data types:
|
Data type
|
Count
|
|
Code
|
6377
|
|
Decimal
|
2984
|
|
Text
|
2310
|
|
Integer
|
1603
|
|
Boolean
|
1452
|
|
Option
|
1279
|
|
Date
|
1025
|
|
Time
|
127
|
|
DateFormula
|
101
|
|
DateTime
|
57
|
|
BLOB
|
48
|
|
GUID
|
17
|
|
RecordID
|
6
|
|
Duration
|
2
|
|
TableFilter
|
1
|
|
BigInteger
|
1
|
|
Grand Total
|
17390
|
From this table you see that most used data type is Code – of course, because most of relations are made through some code and the code fields are used everywhere…
Second is Decimal – yes, we are working with ERP which counts money, inventory…
Tab 3) Field data types including length:
|
Filed type and length
|
Count
|
|
Code10
|
3387
|
|
Decimal
|
2984
|
|
Code20
|
2871
|
|
Integer
|
1603
|
|
Boolean
|
1452
|
|
Option
|
1279
|
|
Date
|
1025
|
|
Text50
|
973
|
|
Text30
|
672
|
|
Text80
|
253
|
|
Text250
|
188
|
|
Time
|
127
|
|
DateFormula
|
101
|
|
Text20
|
87
|
|
DateTime
|
57
|
|
BLOB
|
48
|
|
Text10
|
39
|
|
Code30
|
35
|
|
Code3
|
21
|
|
Text100
|
20
|
|
Code250
|
19
|
|
Code50
|
17
|
|
Code100
|
17
|
|
GUID
|
17
|
|
Text65
|
16
|
|
Text64
|
8
|
|
Text38
|
7
|
|
Text200
|
6
|
|
Text249
|
6
|
|
RecordID224
|
6
|
|
Text5
|
6
|
|
Code80
|
5
|
|
Text119
|
4
|
|
Text70
|
3
|
|
Text99
|
2
|
|
Text90
|
2
|
|
Text19
|
2
|
|
Text150
|
2
|
|
Text199
|
2
|
|
Code130
|
2
|
|
Duration
|
2
|
|
BigInteger
|
1
|
|
Text7
|
1
|
|
Text127
|
1
|
|
Text3
|
1
|
|
Text14
|
1
|
|
Text151
|
1
|
|
Text63
|
1
|
|
Code2
|
1
|
|
Text131
|
1
|
|
Text220
|
1
|
|
Code98
|
1
|
|
Code1
|
1
|
|
TableFilter
|
1
|
|
Text118
|
1
|
|
Text149
|
1
|
|
Text31
|
1
|
|
Text32
|
1
|
|
Grand Total
|
17390
|
Most used is Code with length 10 – all basic lists are referred by this data type. But newer the longer fields are used (Code 20), which have enough space for possible longer codes. I personally when I create new table, I use the Code 20 to precede possible problems with additional extension of the field in future. Very interesting are field length at the end of the table like Text118, Code1, Text63…
Tab 4) Overall stats:
|
Tables
|
918
|
|
Fields
|
17390
|
|
Fields per table (Avg)
|
18,94
|
|
Average count of relations per table
|
7,099
|
|
Percentage of fields referring other fields
|
37,47%
|
|
Max fields in table
|
176 (Tab 39 - Purchase Line)
175 (Tab 27 - Item)
|
|
Max table relations per table (All)
|
93 (Tab 18 - Customer)
|
|
Max table relations per table (Table Rel)
|
66 (Tab 81 - Gen. Journal Line)
|
|
Max table relations per table (FlowFields)
|
63 (Tab 18 - Customer)
|
|
Most referred table
|
266 (Tab 349 - Dimension Value)
258 (Tab 308 - No. Series)
235 (Tab 15 - G/L Account)
|
I think that the last table doesn’t need any explanation. In average, if you change some field’s length, there is more than 1:2 chances that you need to change length of another field which refer to the first field.
I hope, that you made better picture of the complexity of whole Microsoft Dynamics NAV system. May be that you now understand, why the people around this system needs long time to gather enough experiences to understand the system. It is why the NAV is so great product, because regardless this complexity, it is easy to change and develop additional parts. Do not forget that these stats are just for the basic version of the system. If you add all addons which customer needs for his work, these stats can go much higher…
I want to congratulate to all consultants and developers, which are able to understand the system, which knows, how it works, and which are able to correctly do their every-day work with this huge amount of information. May be that this stats will help customers to understands, why sometimes there are some bugs in the system, why some things needs more time to think them out than making them.
We will see how these stats will change with new versions.
August 20th, 2008
Posted by
kine |
Dynamics NAV |
no comments
Today I have for you something, what everyone wants to have, but it was nearly impossible to create. After you see it, you will know why. I prepared it for you in more formats. You can look at it as PNG file, you can walk through it with some VRML viewer, you can open it as Visio file. You can read it and import it as CSV file. You can browse it as HTML file. You can view it as SVG file. It is on you, how you will visualize the result. I must say, I have tried many ways, but in most cases the tools were weak and my 2GB of RAM was not enough.

What’s the hell is this “line hell”?
Ladies and Gentleman,
“Big Picture of NAV” is there. You can download the files on the “The Art of NAV” project page. And what the files are about? The files are generated from data, describing ALL NAV TABLE RELATIONS WITH CONDITIONS AND FILTERS. In the visualizations, the tables are represented by boxes where first line is table name and rest are all fields in the table. The relation descriptions are part of the edge text (source conditions, target filters). All is based on NAV 5.00SP1 W1 objects. When you take the result files and you will want to print it in 1:1 scale, the output will be over 5×5 meters in size. Visio cannot save the diagram as bitmap for 1:1 scale (it seems because the size). You cannot see whole diagram in Visio (on common display resolution), because zoom cannot be less than 1%. My computer had problems to generate any graph from the sources. My 3GHz Core 2 DUO worked on it many minutes. I have used the excellent software Graphviz to make the graphs, but as you can see, it is too much for any tool on the world to make some nice readable chart (or I didn’t find the correct settings :-)).
I prepared for you NAV objects, which I used to extract the relations from object text file. It will fill the NAV table with all necessary data and you can browse it in prepared window. You have list of all fields in the database on top, related tables for selected field in middle, and fields relating to the selected field on bottom. You need to use these objects on the database, from which the object file is created, because the form is based on the virtual tables of the database. The objects are extracting 100% of relations in the database, which are defined. You can use them to extract relations from you own databases. Just export all tables as text and run this tool in the same database.
All files can be found in the download section of project “The Art of NAV“.
Do you understand now, why we do not have any official diagram with the NAV table structure?
File description and viewers I tested:
SVG – vector format – ZGRViewer – sometime needs to set bigger java heap by adding parameter “-Xmx512m” (the size is on you, this example is 512MB) when calling the java package
HTML – HTML exported from MS Visio – Internet Explorer – use the Internet explorer, you can search within the graph. Firefox is showing just plain bitmap.
VRML – the graph in 3D world – FLUX Player – needs big memory, you can look at the graph in 3D space and if you use the FLUX studio, you can add cameras, interactivity, animations etc. Welcome into “NAV Space”.
VSD – MS Visio file created by importing the SVG file – MS Visio – You can look at the graph in Visio and print it from there (over 5×5 meters). Hart to edit etc. because the size and SVG source limitations…
August 4th, 2008
Posted by
kine |
Dynamics NAV, Uncategorized |
no comments
That’s the question… Many rookies have problems with decision where to put the code (or from where to call it). When you watch some beginner in NAV where the code is placed and from where it is called, you can find out that in many cases used triggers are the triggers, which in 99% are not used in the application and many Pro developers nearly do not know what the triggers are doing :-).
I had a thought. To create small decision tree which can help developers to find out, which trigger will be best for calling the code, and where to place the code in (table, codeunit etc.). I placed the first file to google code repository site under project named “The Art of NAV“. I will try to keep this site as the Home page of this project. We will see, maybe I will find better tool for that.
I am waiting for your opinions and comment. I will try to keep the project live and up to date. We will see, if it helps you.
This is a first step I am doing and I am thinking about it as an initial step for something I am calling “NAV Art” or “The Art of NAV”. My target is to help all developers to make the code as clear as possible and make some order in the NAV word. Of course, there is no simple manual or something for that, but I want to open some discussion about that and give some ways for the specific problems. I hope that I am not alone in that and you all will try to participate in this.
I am Waiting for your comments…


July 28th, 2008
Posted by
kine |
Dynamics NAV, Uncategorized |
no comments
Story
Today I solved one “mystery” which leads to data loss. But from the beginning…
We have upgraded HW and MS SQL to version 2005 on 64bit platform. Everything without problems, because SAN was used, transferring the DB was just Detach/Attach and running one SSIS task to transfer user logins. No problem. After upgrade all is working without problems. But…
Some users started to complain that specific functionality is not working correctly. What’s going on?
From one card you can open another form through button. This form shows some related records, and if there are no related records, they are generated. It’s simple. But now, user opens the form and there is nothing in it. I tested it and it works ok, records were created. Ok, I have something to think about and something to solve.
After few rounds of “you’ll try it, I’ll try it” we noticed, that when the user open the form, there is just one line in the form, looking as inserted (no asterisk on left side of the table). But after we moved cursor or just opened table filters and returned back, there is no record in the table and we are on the new line. 8-|
Ok, code looks correctly, no conditions or something else preventing the record insertion process. I started client monitor and there are all the inserts statements, but still no records in the table.
I will not go deep into the analysis of this problem, if you are interested in what I did to discover the source of the problem, post comment and maybe I will wrote another article about that. Now, I will jump to the time, when I found out what’s the problem.
As everytime, the SQL Profiler helped to discover the problem. In profiler I enabled the tracing of Server errors and exceptions and after I catched the process, I saw few red lines saying this:
Exception 74 Error: 262, Severity: 14, State: 4
User Error Message 74 SHOWPLAN permission denied in database ‘blablabla’.
Ok, it confirmed one thing I noticed at very beginning – if you are db_owner, it is working. If not, you have the problem. After looking into permissions and comparing the permissions from DB created on SQL 2005 and on the transfered one, I found out that there are no Database permissions “Show Plan” and “References” for the application role $ndo$shadow.
Result
Why they are not there? Because these permissions doesn’t exists in MS SQL 2000. They are assigned correctly when you create the DB on MS SQL 2005, but not when you transfer the database by Detach/Attach or Backup/Restore process. These permissions are not created even when running Synchronize all process from within NAV (using Standard security model of course).
Another thing I noticed is that this bug makes visible problems only if you are working with Maximized NAV windows, if you are working with form in normal size, all seems to work correctly.
Conclusion
After upgrading MS SQL 2000 to MS SQL 2005, if you are not creating new DB but using Detach/Attach or SQL Backup/Restore process to transfer the database, you need to grant “Show Plan” and “References” permissions for the application role “$ndo$shadow” on the database. Do not forget this else you can experience mysterious data lost and behavior.
Details of the bug
The data are generated in OnRun trigger of the second form. After this trigger is finished, the first form started to be updated, because the OnAfterGetCurrRecord trigger of this first form is called and there is CurrForm.UPDATECONTROLS command in it. Because this process is still running in context of the transaction started with the OnRun trigger of second form, and because there are SHOW PLAN statements in it and the SHOW PLAN permissions are not granted to the app. role, SQL server raise exception “permission denied” and the transaction is rolled back. But NAV client doesn’t catch this exception, and this is the main problem. The first form refresh process is not started if you do not have maximized forms. But the permission exception is triggered every time the forms are using internally COUNTAPPROX to read expected record count (may be because the scrollbar size?) and these calls are canceled by this. User does not know anything about this permission error…
This bug is rare to experience, but the permissions problems can be source of another bug which is not so easy to find or even notice it.
Repro steps
- Create new DB on MS SQL 2005, restore Cronus DB into it
- Remove “Show Plan” permissions from $ndo$shadow app. role on the DB. (or you can detach come cronus database from MS SQL 2000 and attach it in MS SQL 2005 - the permissions will not be there, because they are not exist in MS SQL 2000)
- Import attached objects
- Run form 90001, maximize it (this bug makes a problem only when the windows are maximized!)
- Click “Test - Run Form”
- Second window will open (maximized) but the window has no entries (or just one, until you open filter window or move the cursor, after that there are no lines in the form)
- Restore the windows size, close the window opened in step 6
- On restored window (not maximized) click again “Test - Run Form”
- Second window will open but this time with entered entries - it means correctly.
Objects for download.
February 6th, 2008
Posted by
kine |
Bugs, Dynamics NAV |
no comments