• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 16. Transaction Processing > Using Transaction Processing in a Client/S...

Using Transaction Processing in a Client/Server Environment

When dealing with transactions in a client/server environment, you must consider several additional issues: when and how transactions occur, what types of transactions the server supports, and what types of problems can occur. When using Access in a client/server environment, it is always best to implement transaction processing on the server rather than in your ADO code. Chapter 8, “Designing SQL Server Stored Procedures, User-Defined Functions, and Triggers,” covers transaction processing on the server. This means that if all of your update code is in a stored procedure, and the stored procedure contains transaction processing, you can roll back the transaction at the server level and then pass a status message to the client indicating that things went awry. No data is updated on the server.

Implicit Transactions

When explicit transactions are not used, the way in which transactions are committed on the database server depends on what types of commands your code executes. In general, every line of code has an implicit transaction around it. This means that there is no way to roll back an action because it is committed immediately on the database server. The exceptions to this rule are any SQL statements issued that modify data. These SQL statements (UPDATE, INSERT, and APPEND) are executed in batches; a transaction loop is implicitly placed around the entire statement. If Access cannot successfully update any records involved in the SQL statement, it rolls back the entire UPDATE, INSERT, or APPEND.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint