Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-09-11 : 14:03:08
|
| Jennifer writes "I find many articles addressing the example of a User say withdrawing funds from 1 account and depositing these same funds into another accont. This example addresses transaction processing(BeginTrans,EndTrans) meaning that the entire transaction must be successful before a commit is done.But what about when you have a Web page that allows users to say "reserve a room". How do you prevent User A and User B from picking the same room at the same time?If there are articles you could point me to - that would be great - I'm not afraid to read - I just can't find an article that addresses this situation.Thanks Guys!" |
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2002-09-11 : 14:52:32
|
| Essentially what you are talking about is called locking. You can find several forum posts and articles here on the topic. There are a number of different ways of dealing with this idea, and I don't know that any one is necessarily best all the time. |
 |
|
|
chadmat
The Chadinator
1974 Posts |
Posted - 2002-09-11 : 14:57:55
|
| One will get there first. When it does, it will take a lock on that room record (And any other records it needs to modify). The second one will wait until the locks are released, and if you have written a good app, it will now realize that the room is no longer available, and report back to the client properly.See:http://support.microsoft.com/?scid=kb;en-us;Q43199and"Understanding Locking in SQL Server" in BOL-Chad |
|
|
|
|
|
|
User A and User B simultaneouly SUBMIT a qry to UPDATE the same row in a table.