Some years ago I wrote a series on validating data in NAV. The second post in this row, called
Validating Data #2: Using VALIDATE, addressed the use of the AL function VALIDATE. From recent experience I would like to update some part of this post as this seems missing in any documentation on VALIDATE, including the
Developer and IT Pro Help for Microsoft Dynamics NAV 2013.
For reading ease I'll rephrase some parts. Let's start with the syntax:
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.
Using the
NewValue parameter calling VALIDATE we can kill tow birds with one stone, as:
Record.VALIDATE(Field,NewValue);is equal to:
Record.Field := NewValue;
Record.VALIDATE(Field);Well, this is said so. And yes, from an
assignment point of this is a valid perception. However, from the Rec vs. xRec perspective this isn't true at all.
Let's make a code example like the one used in the
Developer and IT Pro Help for Microsoft Dynamics NAV 2013 and have a closer look.
Example 1
ResJnlLine.VALIDATE("Resource No.", 'JAN');that corresponds to:
Example 2
ResJnlLine."Resource No." := 'JAN';
ResJnlLine.VALIDATE("Resource No.");[Note that I have changed the code to get it work and comply to coding standards which the example clearly doesn't.]
And we make this run together with the debugger and see what happens.
Example 1
Example 2
See what I mean?
Using the code as in example 1, combining an assignment statement and a call to VALIDATE in one, sets the value of "Resource No." field to 'JAN' but clearly leaves xRec."Resource No." empty.
However with example 2, both Rec."Resource No." and xRec."Resource No." are set to 'JAN'.
Ergo
This gives you the possibility to call VALIDATE differently as given by example 1 and 2. Where in the first case Rec and xRec will differ, while in the latter they will be the same.
Читать дальше