A number of related database queries are best placed under a transaction block where an all or none batch of database queries is executed. Applications in which partial database updates would lead to an incomplete, broken link information storage essentially deem systems unusable due to a lack of data integrity. It is crucial that related SQL queries be placed under a transaction block that is committed if and only if all sub-queries are executed successfully, and that the database is unaffected by the failed transaction otherwise.

This precautionary step can be easily overlooked when focus on projects is often placed on demanding deadlines and feature creep. It is at times forgotten or implemented near the last phase of project completion and often without careful thought. Sub-queries may be left out of a complete transaction block or improperly matched with other criteria for rollback depending on the complexity of the process logic.

The real-world example below has been simplified slightly to emphasize the importance of inventory updates. Inventory is the most commonly implemented application in which transactions determine the effectiveness of a computerized system. Product stock (quantities) must be accurately maintained in inventory in conjunction with other system sub components including order entry systems, product pricing models and transaction logs for inventory auditing.

Eg. A product quantity of 300 is placed on an order
Item quantity 300 must be deducted from the inventory table
Item quantity -300 must be inserted into the transaction log table

If an update of 300 items are deducted from the inventory table stock successfully, but an amount of -300 items are not inserted into the transaction log table due to a database failure then a total transaction log inventory count will yield 300 additional items. Therefore the inventory system will report an incorrect count and the inaccuracy will propagate to affect other system components negatively. In this case item stock and backorders will be allocated incorrectly to orders.

If a network connection terminates or internal database failure occurs during script execution, but the transaction rollback or commit statements have not reached execution then the transaction will automatically rollback after the elapsed database timeout period. The database server timeout period further promotes fail-safe transaction execution.