Understanding the Benefits of Transaction Processing
In Access 2.0, there were many marginal benefits of added transaction processing because Access 2.0 did no implicit transaction processing itself. Listing 20.1 shows code that, when run in Access 2.0, writes the data to disk each time the Update method occurs in the loop. These disk writes were costly in terms of performance, especially if the tables were not located on a local machine.
Listing 20.1 Transaction Processing Using Access Basic as Seen in Access 2.0
Sub IncreaseQuantity()
On Error GoTo IncreaseQuantity_Err
Dim db As DATABASE
Dim rst As Recordset
Set db = CurrentDb
Set rst = db.OpenRecordset("Select OrderId, _
Quantity From tblOrderDetails", _
dbOpenDynaset)
'Loop through recordset increasing Quantity field by 1
Do Until rst.EOF
rst.Edit
rst!Quantity = rst!Quantity + 1
rst.UPDATE
rst.MoveNext
Loop
IncreaseQuantity_Exit:
Set db = Nothing
Set rst = Nothing
Exit Sub
IncreaseQuantity_Err:
MsgBox "Error # " & Err.Number & ": " & Error.Description
Resume IncreaseQuantity_Exit
End Sub
NOTE
![]() | This code, and all the code in this chapter, is located in the CHAP20EX.MDB database on the sample code CD-ROM in the basTrans module. |
- Amount of free memory
- Number of columns and rows being updated
- Size of the rows being updated
- Network traffic
If you plan to implement explicit transaction processing solely to improve performance, you should make sure that you benchmark performance using both implicit and explicit transactions. It is critical that your application-testing environment be as similar as possible to the production environment in which the application will run.