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-04-01 : 09:13:31
|
| Gary writes "I have two questions. Using VB I want to be able to display a "record maintenance screen" on multiple clients at any given time. I will be using adLockPessimistic to lock the row. If User A successfully changes the record, I don't want User B to be able to change it without refreshing it. Is there some sort of special lock to accomplish this? Or a SQL technique that will tell me that the recordset has changed?Also, I am familiar with the Transaction techniques when working from SQL Query Analyzer. However, I don't know how to do multiple SQL statements from VB code. Can you help?Thanks -- what a great web site, by the way!Win 98, 2000 / MS SQl Server 2000 / VB 6.0 SP 5" |
|
|
rrb
SQLTeam Poet Laureate
1479 Posts |
Posted - 2002-04-08 : 04:14:10
|
| GaryAs regards doing more than 1 SQL command from VB - I've never tried it. However, I'd suggest you should probably either:do each call separatelyORwrite a stored procedure and call that from VB.Personally, I'd slant toward the second of these options. It would also make things easier for roll-back etc etc etcwrt your first question - I would think the only way to accomplish this would be to requery the rows at the beginning of User B's attempt to change the record, and check to see whether it has been changed - ie "no". However, someone else may know a way... If nothing else, at least I've kicked your question back to the top of the list...Cheers--I hope that when I die someone will say of me "That guy sure owed me a lot of money" |
 |
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2002-04-08 : 08:46:18
|
| You can write your updates to have the old data in the WHERE clause, so that if another entity updates it first, the second update will not change any data.It's better though to handle the screen-locking semantics in your application. You may run into a situation where one screen is responsible for updating more than one row, or one row in each of several tables ...setBasedIsTheTruepath<O> |
 |
|
|
|
|
|
|
|