Article Preview
Buy Now
| Print: | |
| PDF: |
Object-Oriented Thinking
Automatic Transaction Rollback
Leverage REALbasic Memory Management
Issue: 5.2 (January/February 2007)
Author: Charles Yeomans
Article Description: No description available.
Article Length (in bytes): 5,391
Starting Page Number: 37
RBD Number: 5214
Resource File(s): None
Related Web Link(s):
http://www.declareSub.com/
Known Limitations: None
Excerpt of article text...
Database transactions require a lot of error-checking code. However, we can take advantage of memory management in REALbasic to simplify error-checking and make it more robust.
Here is a typical example block of database transaction code.
Sub PerformExampleTransaction(db as Database)
db.SQLExecute "INSERT INTO table1 ('foo')
if db.Error then
db.Rollback
return
end if
db.SQLExecute "INSERT INTO table2 ('foo')
if db.Error then
db.Rollback
return
end if
//etc.
db.Commit
exception oops
db.Rollback
//re-raise exception or not, depending on general error-handling strategy
End Sub
The problem here is that you have to check for an error after each database operation, and roll back the changes if an error occurred. You also have to anticipate the possibility of an exception and roll back changes if one was raised. For the example code above, this is simple. But note that most of the code above is devoted to error-handling. For a complicated transaction, this will add up. More code means more opportunities for bugs. Worse yet, most of the error-handling code is repeated. What happens when we decide to change how we handle errors?
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
