I have 2 number fields, Main_Number and Change_Number. Main_Number is validated by a calculation to allow only certain values and does not allow overrides. I'm developing a script which replaces the data in Main_Number with a user-entered number from Change_Number. So, simply enough....

....(other script steps)

SetField[Main_Number,Change_Number]

Clear[Change_Number]

Go to Field [ ]

Halt Script

If the validation fails, the Revert Field/OK box pops up. If I select Revert Field, the field doesn't revert and instead allows the 'incorrect' value. There is no problem if I use Insert Calculated Result or Copy/Paste instead of the SetField script step, but shouldn't the reversion work with SetField?

The 'Set Field' script step bypasses the interface to enter data directly into the field - whereas the 'Insert' and 'Paste' script steps use the interface in much the same way as a user does. 'Set Field' bypasses 'Allow entry into field' restrictions, works on fields which aren't on any layouts and even works on fields in another file. If anything, I'm more surprised that you are even getting a validation dialog than I am that the validation is being bypassed.

When designing script techniques using 'Set Field' one should generally consider trapping for errors (using the "Set Error Capture [On]" and "If ["Status(CurrentError) = n"] Script steps) rather than relying on the interface-based default error detection. Although it's a little more work to set up, it will ultimately give you (and/or other users of your databases) less grief.

I've found...

Set Field []

Exit Record/Request

... usually brings up any field validation messages with scripts. Trapping for the errors is a bit trickier fo course. The exact procedure dpends upon the interface: I try to design the processso the script can be exited if there is validation error; second best is a loop that keeps the users in the script until either a valid entery is made, or they cancel out somehow.