FM Date validation fails

[LaRetta]

Our Invoices pre-fill ScheduledShipDate with the next allowed shipping date (Auto-Enter, Do Not Replace). Staff is allowed to change this date if customer requests it be held (two weeks, for instance). But when they change the date and enter an INVALID date, the process fails. FM allowed a ScheduledShipDate of 5/9 /2006. And FM could never identify which day portal it belonged to so it never displayed in any date-related portals and was never identified as needing to be shipped (since I use GTRR instead of a Find)!!

Attached is a sample. Invoice window is locked in place until script validations all pass. If any validation fails, script tells User the problem and then halts. I have imported the portion which checks the ScheduledShipDate. Change the current default date from 5/28/2006 to 5/33 /2006 and immediately hit CTRL-1 (to fire the script). Even adding Commit Records/Requests to the beginning of the script doesn't stop it from breaking. It displays several ? in the Custom Dialog as the date so FM knows it's invalid. I REALLY want to understand how ANYTHING can get past FM field-level date validation!!

LaRetta :confused:

InvoiceComplete.zip

[mz123]

Wow! I wouldn't have believed you (no attack on you, of course) without that example, just because it seems so obvious that Filemaker would catch it!

Could you create a set field:

set field[Field;

Filter( Substitute ( Field ; "-"; "/"); "1234567890/")

i would do the substitute to / so that if someone enters - as the date marker, it won't get removed in the filter (I guess you could put both /- in the filter though)

Craziness though. Still amazed at FM...

[LaRetta]

Well, I've spent a few hours on this problem, Martha. And ... the moment I posted, I realized my error (in the demo file at least). I had a Commit (but with 'Skip Data Entry Validation') - ooops!

However, my original file has several If() tests with NO Commit at the beginning. It has one Commit at the very end after all validations PASS. THAT Commit has 'Skip Data Entry Validation' and I guess that's why it's failing. When I uncheck 'Skip Data Entry' in the test file, it works.

So my question has changed a bit (blush) ... why is FM not catching the error if the Commit is outside all If() tests and at the end? Is that what is breaking this process? I need to understand this one. If I need to add Commit (uncheck 'Skip Data Entry') then I want to understand how FM thinks through this so it never happens again! It sounds like I will always want to add a Commit (Don't Skip Data Entry) any time a date is being changed!

We had one very upset customer (and rightfully so). We told them the computer broke.

LaRetta

[comment]

why is FM not catching the error if the Commit is outside all If() tests and at the end?

I believe it does - provided that Skip is unchecked, and that the date is still uncommitted at that point (before testing, you need to clear the field and enter a fresh invalid date).

[LaRetta]

Yes it does. So if I have ANY field-level validations in a window (User has modification access), it will be important to start ANY script with a Commit Records/Requests [ ] (meaning it will validate data-entry). Otherwise field-level validation can fail. I think this is important, thank you!

I confess ... I start my new window scripts with Commit ... but always CHECK 'Skip Data Entry.' Not good. It seems important to let that validation run on the current layout (window)BEFORE opening a new window or changing layouts. I don't want User to be able to pull up their cursor and leave. I guess I'm just realizing that, over and above the almighty script, field-level validation should always take priority. Otherwise the User can get away or other things can go wrong.

L