Sorry...I didn't read your whole post earlier...yes...the parameter is in the sproc. I was assuming that is why I'm getting the error from the data layer.

In the BO, I set the optimistic concurrency to rowversioning and then entered the name of the field (ROWVER) in the rowversion name field.

I tried using a sproc with only the Row ID (an Identity field) as the WHERE clause and changing the BO to not use any concurrency and it works fine.

That's a good sign....what does your update sproc look like now?  Does it have the ROWVER parameter in the where clause?  If not, then your sprocs are not getting deployed or rebuilt properly.

Just one other thing...you did set the table properties to RowVersioning and provided the ROWVER field...correct?

Hi Trent

I created a field name ROWVER as an INT and changed the options to use RowVersioning. Now it tells me that the sproc needs @ROWVER but its not provided.

Clayton...can you try something for me.  Before I try to dig out all of the stored procs settings, can you add a row version field to you table and attemt to use Row versioning.  The WHERE clause of your stored proc will basically go to nothing...but I just want to see if this resolves your problem.

Just add an integer field in your table.  Open the table properties and indicate that you are going to use row versioning and provide the version field. (obviously deploy your structure).

Go to the CRUD settings on your BO and change the following properties:

UpdateConcurrencyType = OptimisticRowVersion
RowVersionOrTimestampColumn = "YourRowVersionFieldName"

Rebuild and try this again and see if the error persists.

Trent...I sent the sproc to your email.

Hi Trent

Here are my DDT settings

One other thing to look at...open the stored procedure through the SQL Server Management Studio (or Enterprise Manager) and let me look at it here.  Also, I will need the table structure so I have something to compare it to.

Well, just to remove any confusion let me give you a quick overview so that you can make sure all of the BO properties are set properly.

Database Deployment Toolkit
Here is a table where I am allowing the DDT to create my stored procedures.

In this example, my table name is TestNames and you can see the default names that are generated.  You can rename the stored procs, but if you do you will need to specify the procs names on the BO explicitly.

BO CRUD Settings
Here are the CRUD settings that are set within the property sheet of my business object.

In this scenario, this is all that needs to be done in order to properly update your table using a sproc.  Notice that I did not specify the InsertStoredProcedureName or UpdateStoredProcedureName.  The reason I could do this is because of the default naming schema expected when using the DDT.  If the sprocs do not match the schema: TableName_Insert, TableName_Udpate, and tableName_Delete....then you will need to set the StoredProcedureName properties.