On 12/30/98 12:56:07 PM, Toni Eibner wrote:
> OK, I've witnessed this problem first-hand now. If user1 opens a
> record and makes a
change (but doesn't save it yet) ,user2 opens the
> same record and makes
a change,user1 saves the record and then user2
> saves their record, all my changes
are overwritten by whatever user2 has
> done. Why is this happening??? Better
yet, what can be done to correct
> this?
> Toni Eibner

Toni,
This is because you're working with a result set rather than "sitting on"
the record the way you might in an xBase, Access, or other PC DBMS. This is
as it should be, it's the way SQL products are designed. Nigel's suggestion
of using a Timestamp column for concurrency checking is the way we handle
this in our applications. If you start doing a lot of explicit locking
you're sort of limiting SQL Server's abilities and performance by making it
act like a PC database. If you want to have some fun, start a discussion of
whether or not concurrency checking (by locking or otherwise) is even
necessary. That used to be good for lots of "discussions" on the Compu$erve
SQL Server forum. In many of our databases, "last one in wins" actually
works best and lets SQL Server do its stuff at full speed so we've started
implementing that instead. My front end developers like it also since it reduces their workload a good bit.
Bryan