Page Comparison

In the world of conventional (relational) databases, transactions keep data consistent. Orphan records or records with half-baked columns make a mess and confuse the software. The idea behind transactions is to assemble data in memory, set up the relations between them and commit them to the database in their entirety when they are fully initialized and have been bolted together. If something goes wrong and objects can't be created as planned, the database program simply does not commit anything and leaves the database as it was. This atomicity and isolation is also the central idea of re-store's transaction model. In contrast to relational databases, re-store's client transactions are not determined by how data is structured or how it depends on other data. Instead, client transactions are designed around what the user does. Usually a client transaction (that's how re-store transactions are called) spans a unit of work, and these client transaction can embrace long and complicated operations. In order to keep things clear, we will use the re-store term "client transaction" to make these differences more explicit and distinguish them from regular database transactions. Make no mistake, however: behind the scenes, for actually persisting data, the MS SQL Server uses common transactions, but their nature and design is completely hidden from the programmer who is working with re-store client transactions. DELETE ME