Data Validation, you're doing it wrong! with AL in Business Central
HTML-код
- Опубликовано: 9 ноя 2024
- Well, not you of course, but everyone else is doing it wrong :)
Find more information at my blog www.hougaard.com or follow me on / ehougaard
Source code can be found here: github.com/hou...
More beginner type videos like this please! Great content to learn from when doing app dev for BC
i think that the message could be - know the "base" - then you can decide whether to validate or not (and when not validating, live with the "consequences") - but you are right, better validate than fill all the missing stuff later (or worser - forget to fill it)
Not anymore (you could argue that would work in NAV), because you don't know the future base, if you're not validating, then a future event subscriber to that field will not get your validation
Another great topic!
Looking at the field order on the Page/Form was the way I learned how to fill out GenJournalLines and other "tricky" records like that :)
There is ONE case, where I'm in a little conflict with myself... Should I validate fields that are copied from another record?
I.e. I validated "Customer No." which should then fill in 'Customer Name'... Should I validate or copy 'Customer Name'. I kind of expect the interesting things to happen at 'Customer No.'.
Right now I am validating, but even from 'Base Application' I see them copy in cases like this.
Always validate.
The best extension citizen in the World!
Thanks for your effort Erik, you've helped me overcome some hard situations!
I have one question about this topic. What would be the best place to trigger validates in if a user makes a change in a record using the GUI? Inside the Table or in the Page?
Cheers!
Great question (that's video-worthy) - Always table... If a page trigger seems the right choice, then you're properly doing something wrong.
@@Hougaard Thank you a bunch! 👍
From the database perspective, how insert/modify pattern is better than just insert after you validate all the fields? You have to call two triggers Instead of one which is slower.
Yes, but there's lots of field validation code that's written with the expectation that the record is inserted, this will either fail loudly or worse, fail at some point where an event subscriber will fail, and take your code down with it.
Is there known name for pattern that you describe (init, insert, modify), or how do you call it?
Dunno, the "BC Pattern" :)
Thanks!.. now I have to re-write some of my bad coding.. :-)
Looking at the code from this video, it screams to me that there is a problem with not validating your data before inserting a record.
You are doing the SH.Insert before you have validated that you have good data in the rest of the fields.
Why would you want a sales header which does not have a sell-to customer or other (what I would think are) required fields?
I know in your video, you're doing Validate triggers and a modify immediately after the insert, but there's nothing that requires you to do that.
I could conceivably programmatically insert a record with only primary key fields, and nothing in other business-required fields
I found a problem with your UI example of adding a new customer on the CRONUS database.
I click new, choose a template, and immediately click the Back button on the page.
The customer record has been saved, but there is no name on it (which is a required field), no tax area code (which is a required field), and nothing at all in any other fields.
I would expect it to stop me from closing the page, either telling me to fill in required fields, or telling me to cancel the add of the record.
If I was doing this programmatically, there would need to be some exception handling, throwing an error if required fields were not populated
Something to the effect of
if not Mytable.Insert(true) then
error('Insert did not succeed');
This is assuming that the Mytable.Insert(true) would return False if a required field was not populated. That may be an incorrect assumption in Business Central.
I am on version 18.5.29545
- The quick Insert is actually replicating the behavoir of the client. The record should exist before you're validating sell-to.
- But there's nothing in AL that prevents you from creating BAD data in any table.
- The "required fields" stuff is not preventing you from inserting a empty record, that's just how BC works.
- Yes, you're assumption is incorrect, that is simply not how BC works.
... Don't fall into the trap of believing that BCs database is behaving just like the rest of the world, it's not. We started with a native database that was not SQL, and then the methods from that got translated into AL/BC.
Validation should be done at doc level, not record/field level. (in business apps I mean, doc oriented by definition). Just an old consultant opinion, struggling in the field with confused end-users about circular validations and stuff.
Not sure I truly understand what you mean by "doc level"?
@@Hougaard Like when a salesInvoice is not "valid" unless total = sum of amount by lines, but also unvalid if not in a package with a warranty certif. ( making it a composed doc of some sorts).
Business Central do not have a concept of warranty certificates, are you referering to Business Central/NAV issues, or another system?
click bait indeed, coz i went to the school of Erik :)
Well, you know the content of this one :)