You can precede Commit Record with Set Error Capture [on] to suppress this error message.
Unfortunately, this suppresses all the error dialogs--including the validation error messages--so it may be a better approach to add your own scripting to check for required values and not commit the record at all if there are missing values.
Yes, unfortunately I had tried exactly what you suggest, but the side-effect of suppressing the validation is a deal-breaker. Manually validating the commit via script is also problematic, because I plan to apply this script to a large number of tables.
Any other suggestions would be much appreciated :)
Can you describe why you want to use a script to commit the record? This is often not needed in a FileMaker solution. With that info in hand, we might be able to figure an approach that attacks this from a completely different direction.
To answer your question, let me present a simplified version of my problem:
Lets say I have tables for Widget A and Widget B, and Widget B must always include a Widget A. I am basically trying to put a button on the Widget A layout that says "Create a Widget B". When pressed, the button grabs the serialized ID from Widget A and auto-populates the relevant field in the Widget B table, so the user does not need to worry about this step. I have the "Commit" step in case the user has just finished creating a new Widget A record and presses the button before "commiting" the record by clicking on a non-field region of the record. If the user has filled out the required Widget A fields, the script would then go ahead and commit the record so that the serialized ID becomes available.
To put things a different way, my tables are unusual in that they have the relationship A->B->C->D in which A can have many B's but every B always has exactly one A, and so forth...
Please let me know if you need further clarification...
Then why not have the serial number auto-enter "on creation" instead of "on commit"? That would seem to avoid this whole issue.
The reasons are:
 I do not want the serial to auto-enter on creation because I do not want the serial to increment in the (quite frequent) cases where a user starts entering a record but then changes his/her mind and deletes the record.
 The problem still would exist if the user pressed the button before filling out the required fields in the record
1) why is such a missing serial number an issue? (Such serial number fields in FileMaker usually serve as primary keys and should be kept hidden from the user anyway.)
2) So far, the only required field you've described is an auto-entered serial number so I'm a bit in the dark here.
Your table structure: A--<B---<C---<D (---< means one to many ) seems pretty normal. What seems odd when looking at this in the abstract, is that you appear to allow the user to create a "child" record in table B before they have created the related "parent" record in table A.
 Table B needs to know it is a child of an entry in Table A, hence the transfer of the serial number from A to the new record being made for Table B.
 There are some fields in Table A that are not allowed to be empty and/or have other validation constraints (such as numeric). If the user has filled out their record but not triggered the validation and commitment step (which seems to require taking focus from the fields), pressing the button will trigger both the validation error and the script error dialog. I'm just trying to find a way to abort the script quietly if the validation error dialog is shown.
 yes I get that, but why do gaps in this series matter? As far as I can tell, that's the only result of starting a new record and then deleting it. If the gaps don't matter, then switching your serial number field from "on commit" to "on Create" should work for you and will make life much simpler.
 I understand what you are wanting to do and if you don't want to pursue the direction I've taken your thread, I totally understand and apologize. I'm just trying to search out an "end run" that avoids the need for your script to commit the record in the first place.
Working with someone on their database solution via an online forum is often like peeking through the keyhole of a house's front door and trying to figure out what color paint was used in the bathroom ;-) That can lead to suggestions that are less than optimum simply because I don't have a complete enough view of the entire system.
Let's take a look, if you want, at your basic set up here: You have parent record A and child record B. If you design your interface so that a valid record in A must exist before the user can create a new B record for it, then it would appear to me that most of your design issues get a lot simpler.
Here's some "brain storm" ideas that you can consider to see if they work for you:
A script perfomed from A can easily create a new related record in B, taking the user to a layout for that new record and opening it for editing so that the required field validations will then apply and there's no issue with a "premature commit" in a script. You can even pop up a window for this data that simulates the modal behavior of a dialog box so that the user is required to complete and commit the new child record's data before returning to the parent record.
You can use Commit record with no dialog and skip entry validation to temporarily commit a record. The script can then use Open Record at the end of the script to return the record to its open state so that the field validations will automatically kick in when the user commits the record.
Thanks for the ideas... you are right that it is a bit difficult to communicate the problem via a forum :). I will probably end up using some variation of the ideas that you presented in your last message. Thanks for your time!