Article Preview
Buy Now
| Print: | |
| PDF: |
More About Multi-User Applications
Article
Issue: 5.6 (September/October 2007)
Article Description: No description available.
Article Length (in bytes): 4,419
Starting Page Number: 40
RBD Number: 5614
Resource File(s): None
Related Link(s): None
Known Limitations: None
Excerpt of article text...
As we saw in issue 5.4, converting a single-user database for use with REAL SQL Server is a pretty easy task. But even though your application now works on a server, you still need to think about how it might be affected by having multiple users accessing it concurrently. If you've ignored this design problem then it's most likely that your application will exhibit some strange behaviors, such as other users being unable to use the system when someone is editing data or having changes made by one user appear to not be saved.
So, how do you deal with these issues?
Transactions
The first thing to consider is your use of transactions. A transaction is a way to group a set of database changes so that they either all succeed or all fail. While a transaction is pending, it can sometimes cause other database access to pause. For best results you should explicitly control your transactions. This usually means that you create the transaction, make your changes and then complete the transaction. Do not leave a transaction open while you await user input because you have no idea how long that will take and run the risk of locking out other users.
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
