All around NAV dev and test
I regard myself one of the lucky ones that had the chance to attend a class by Bj Rollison. An inspiring test veteran who, in all aspects, exhibits the notion that testing is more than just trying code and finding bugs. Through MSDN I stumbled across his blog, which he recently moved over here.
To me yesterday's post title describes Bj's blog theme in a nutshell: Thinking About Critical Thinking And Test Design. Read and get inspired!
For a couple of months I have been subscribed to MSDN blogs RSS at the danger of being bombed with loads of blogs post. And because of that probably once every day I did consider to unsubscribe. But every now and then, up till today, I am surprised by a blog post that makes sense to me. Which otherwise I would have missed for sure. So today it seems, like every now and then, worthwhile, seeing this blog post by Mehdi EL YASSIR: Astuce #1 : Propriétés ShowAsTree et Style.
Uhhhh, it's in French as you will find out. I love French and could even translate it for you, but I think you are intelligent enough to understand the whole thing. If not I'll read your comment below.
Writing my blog post How-to: Search a Field in Table Designer I fully forgotten to mention that in a similar way you can search in C/AL Globals and C/AL Locals.
Be it Variables:
.. or Functions:
... or Parameters:
... or Text Constants - although in general this will not help you much as most (standard) text constants start with the letter T.
All you need to do is to:
Select all lines and press the same key againEventually the system will not deselect the lines and you can continue pressing the same key and in this way jump through all records with a name or data type or subtype (...) starting with that letter.
Whereas validation of user input is one side of the medal, the other is validation of code entered data, the subject of this blog post.
Just as any user input code entered data should be validated before it is allowed to be recorded in the database. A standard way of entering data through code is by the assignment statement:
"Search Name" := Name;
Like in the OnValidate trigger of the Name field on the G/L Account table, where the Search Name field of a record will be assigned the content of the Name field of that record.
By the basic nature of C/SIDE an assignment statement can only be created if the data types match on the both sides of the assignment statement. (Read more about this here.) Hereby data type validation is not needed in run-time, although even if data types match a run time error could occur due to an overflow. (Read more about this here.) . Running the code will however not trigger any (additional) validation.
Now how to trigger additional validations as discussed in my blog regarding the validation of user input? By using the VALIDATE field method.
As the Developer and IT Pro help explains, the syntax for the VALIDATE function is:
Record.VALIDATE(Field [, NewValue])
Where Record (data type: record; subtype: any NAV table) contains the field Field you want to validate. The optional parameter NewValue is the value to be inserted in Field. Needless to say that the Data Type of NewValue must match the data type of Field.
Calling VALIDATE altogether launches a two step process in the following order:
Thus before the OnValidate trigger of the field is executed any system validation will be carried out, like checking of table relations based on the settings of the TableRelation and ValidateTableRelation properties. I.e. the same details apply as have been described here.
The second parameter allows to combine two statements in one, as:
is equal to:
Record.Field := NewValue;Record.VALIDATE(Field);
Having seen a couple of posts on data validation coming by I decided to tackle this issue in a couple of blogs of which this one is the first. Just to straighten out me thoughts and knowledge on this, and share it with you.
Like in any other software system NAV will validate data, entered by a user, before it will allow it to be recorded in the database. This validation process is triggered, once a field has been populated and the user leaves the field. This might be for example by:
In NAV data validation can be seen as a three step process in the following order.
Based on the properties of the field the system will check whether the data entered complies to each property. As an example let's take the Quantity field on a Sales Invoice.
One of the main properties of any field that will be validated is the Data Type property. Being Decimal for our Quantity field this means that only decimal data can be entered into this field and any deviation from that should lead to an error thrown by the system. Like typing the text error in this field:
Next to system validation, i.e. checking the data entered against default properties of the field, a NAV developer has the possibility of programming additional checks and actions on any field. This is done by writing C/AL code on the OnValidate trigger of the relevant field.
As in the example of the Quantity field we see that quite some code has been written (even more than shown in this screen shot).
A third and last level of data validation is given on the UI (user interface), being the OnValidate trigger on to the form control Quantity field:
In case of our Quantity field no validation code has been provided on the UI. Note, however, that action will be taken based on code in the OnAfterValidate trigger after validation as discussed in this post.