If you read Validating Data #3: Cascading VALIDATEs you know by now that a VALIDATE call comes with a price. So where possible the programmer should diminish the number of VALIDATE calls. Or “… to avoid the validate statement when populating records …”, as Marije Brummel puts it in one of her posts.
Sure, I know, if you need to impose business logic on code entered data you need to validate the value assigned. But that’s something different than by default always program a VALIDATE statement to assign a value, “… just to be sure …”, as I recall some of my students said.
Not too long ago I was debugging some code that involved the creation of some kind of journal line. For every field a VALIDATE was programmed to populate – and validate – it. The darn bug I was trying to reproduce and find a fix for, was founded in this simple ‘listing’ of VALIDATES. One VALIDATE was assigning and validating some item related field while a next one was, indirectly, refreshing it based on an Item.GET statement. So this “… just to be sure …” was not only triggering probably a lot of unneeded and duplicate validation code, it was also frustrating a previous action.
Some Rules
Would it be possible to phrase some general rules on when to use a VALIDATE and when not? Let me give it a try and maybe you could provide some additional ones.
Do Not Use a VALIDATE …
… when:
- you only want to assign a value to a field
this is typically something that is the case when posting a journal line to a ledger table; most ledger table fields do not have any validation code behind it anyway
and as Marq states on the same post mentioned above: How many validates are there in Codeunit 80? And 12? - another VALIDATE will call the same validation code
see my blog post on cascading VALIDATEs I referred to at the start of this post
Do Use a VALIDATE …
… when:
- system validation needs to be triggered, for example TableRelation settings, and
- code in the OnValidate trigger should be executed
… but be smart! [8-|]