T
Tom Jorgenson
I'm using disconnected datasets in an ASP.NET web application. I'm using the
automatic locking (that is, I'm not doing anything myself to cause a lock
other than calling an update).
When I go to persist a change in a dataset, it generates a concurrency
violation exception.
The only problem is that I'm the only user of the SQL Server (as well as the
database and table) and this is the FIRST update that's been applied to the
table during this session. This isn't even a new record in the table (or I
might suspect getting caught somehow by a default entry).
So, how can I get a concurrency violation on a table record that couldn't
have been modified after the dataset was originally loaded?
Another question, is it true that the lock (in automatic locking) is applied
only during the update? Could the record somehow have remained locked in the
table even after the session has died? If so, how can it be released
manually?
I'm stumped.
automatic locking (that is, I'm not doing anything myself to cause a lock
other than calling an update).
When I go to persist a change in a dataset, it generates a concurrency
violation exception.
The only problem is that I'm the only user of the SQL Server (as well as the
database and table) and this is the FIRST update that's been applied to the
table during this session. This isn't even a new record in the table (or I
might suspect getting caught somehow by a default entry).
So, how can I get a concurrency violation on a table record that couldn't
have been modified after the dataset was originally loaded?
Another question, is it true that the lock (in automatic locking) is applied
only during the update? Could the record somehow have remained locked in the
table even after the session has died? If so, how can it be released
manually?
I'm stumped.