Validating Data #5: Data- and XMLports

Both a Dataport and XMLport object can be used to import data into Dynamics NAV. And as with user input and code entered data we might need to validate the data imported to impose the necessary business logic. This can be achieved in two ways:

  • either by programming a VALIDATE after the value of a field (or whole record) has been imported
  • or by using the field validation properties CallFieldValidate (Dataport) or FieldValidate (XMLport)

In either case the OnValidate trigger of the specific field will be called. But ... NAV will not act exactly the same in both cases.

What?

Yes, NAV will not act exactly the same in both cases.

Why not?

Well, where to start? As I do not have a clue how much you know about the Rec and xRec system-defined variables. If little to none, you might read this first - although it does not tell you all. I might spend a special blog post on this topic later.Smile

To put it simple - and with this I mean as little as possible words: Surprise

  • using VALIDATE: when we enter the OnValidate trigger both Rec and xRec hold the same data
  • Rec = xRec

  • using (Call)FieldValidate: when we enter the OnValidate trigger Rec holds the data (like with using VALIDATE), but xRec is empty
  • Rec <>xRec

Does it matter?

... you might ask. Well, it might! And this depends on the code in the OnValidate trigger. Ever seen this kind of code?

So in case

  • Rec = xRec, i.e. when using VALIDATE, the second code line will NOT be executed
  • Rec <> xRec,  i.e when using (Call)FieldValidate, the second code line will be executed

So like with calling VALIDATE do not just use (Call)FieldValidate; perform some proper investigations. Be smart! Geeked

Notes

  • By default the CallFieldValidate property (Dataport) is set to No, while by default the FieldValidate property (XMLport) is set to Yes. But there seems to be some deviation as the help documentation tells you if ...:
  • ... the FileFormat Property is set to a value of UPXML for User Portal dataport. In this case, the default value of the CallFieldValidate property is Yes.

    I am just rephrasing it here, so that you know, as I have not been working with UPXML.

  • On an XMLport the DefaultFieldsValidation property allows you to activate the field validation for all fields
  • As stated in the technical online-help:
  • Imported fields are validated in the same order that they appear in Field Designer. The code in the OnValidate (Fields) Trigger might initialize other fields in the record. If this is the case, investigate whether the order that fields are validated is important by looking at the OnValidate triggers of those fields.

    So again: be smart! Geeked

More Information

Anonymous
  • I am not sure if I do understand exactly what you mean, so let me try to give a meaningful reaction.

    Validation of data in NAV should only be done inside NAV using NAV business logic.

    You write: "In real life we need to get validation of more fields in a record" And that also counts for NAV in which you will do that too. Either during manual data entry or coded processes.

    Hope this makes sense.

  • Hi

    I have worked long time with SQL Gupta then Navision, i think it's more easy to create validation field in a private program outside Navision. When you see data is ok (in real production line a data can be bound with a lot of factors) , you then copy it into, for example , the consumption journal.

    In real life we need to get validation of more fields in a record.

Related
Recommended