Michael,
I may need to elaborate on my thoughts a bit.
A Locked flag in the data records itself may be meaningless by itself.
If your business rules state that an invoice needs to be locked to prevent unwanted database changes, this is a security-level requirement.
That means it needs to be enforced at the DBEngine level, and not at an application level.
Therefore, the Form-level code is the wrong place to put this type of logic.
The reason for this is that by itself the Lock flag means nothing to the database engine.
So, if you put code into the application to prevent writing data to a "locked" invoice's details, what's to prevent you or any power user from opening the data table directly in an editable view and changing the data that way (or, for that matter, via a vbscript or external code method)? Nothing - is the short answer. The DBEngine will just do the changes - no matter what your business rules say to the contrary.
This is both good and bad, but it makes for an unprovable audit trail, at the very least, or unwanted and unauthorized data changes, at worst.
This is why security-related rules like you're discussing need to be enforced at the database engine level, and not at an application level; so they actively prevent unwanted and unauthorized data changes, no matter the source or the change request.
Regards,
Mark B.
On 12/28/2025 1:20 PM EST michael simpson via groups.io <saccity101=yahoo.com@groups.io> wrote:
I would like to add a lock to records once an invoice is sent out.. to prevent accidental changes.
My first thought is to add a field (Lock) to each record and then add a before update procedure on each field, many of the fields also have after update procedures,
Can I use both Before and After update procedures,
Is there a better way to lock down records.
Take care,
Mike the Plumber
Sac City Plumbing
._,_._,_
