Hi, good article. Just something you may like to consider mentioning. I have seen this problem several times now and it allows potential for system misuse. The problem is where a screen of data has been entered, has updated the database but this does not get committed until the user accepts the entries from the screen. Consider this theoretical scenario to do with receipting. The user logs into the receipting system and enters receipt data for a cash transaction, but does not commit this. On a second session the user goes into a print routine and prints details of the uncommitted data (as a receipt) and then goes back to the first session and cancels the transaction, rolling out any record of the details now printed on the receipt. The user now pockets the cash with no record of this existing in the system. This is a trap that programmers often don’t consider when using commit processing, and can be mitigated by writing the data to a temporary table until accepted and only then updating the live table.