Rowversion / Timestamp and DAAB frustration

Topics: Data Access Application Block
Jan 30, 2007 at 8:02 PM
Using the new version of the DAAB is the most frustrating thing EVER. I have been stuck on how to handle optimistic concurrency for days now. How are we meant to deal with concurrency with the new DAAB? Why is this so difficult? Isn't this an extremely common requirement? There are hundreds of posts thrashing with this issue and no answers.

Rowversion is of course NOT a datetime. I know it can be represented as a byte8. I have done this in the past with the old DAAB. However, this is not a DBType - which as far as I can tell the new DAAB relies on exclusively. (There is no longer a sqlHelper.)

How do I build the update parameter for the rowversion? These are NOT valid:
defaultDatabase.AddInParameter(dbCommand, "rowversion", SqlDbType.Timestamp, myObject.Rowversion);
defaultDatabase.AddInParameter(dbCommand, "rowversion", DbType.Byte8, myObject.Rowversion);

Even if I CAN do this, isn't it violating the entire point of the DAAB? My understanding is a big point of the DAAB is to abstract the data provider from your application. Now say we move the app to Oracle which uses a TIME STAMP as the timestamp. Now all my byte-array code on every tier is wrong. I've read some cast the rowversion is a bigint right in SQL. How does that help? Can we instead somehow cast it as a varchar which could hold either a rowversion or a datetime? Why would that be wrong? How can I do that?
Jan 31, 2007 at 2:36 PM

I struggled with this when I was working on EasyObjects, too. Here is the correct portable code:

db.AddParameter(dbCommand, "ts", DbType.Binary, 8, ParameterDirection.InputOutput, false, 0, 0, "ts", DataRowVersion.Current, null);

You can't use AddInParameter because it doesn't offer the right options.


Matthew Noonan
EasyObjects.NET -- The O/RM for the Enterprise Library
Jan 31, 2007 at 4:00 PM

Thank you very much for your response!