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?

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.

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

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.

I know that you know how to do this....but I went ahead and created a sample for you to compare your settings to.  You can import the DDT package file with this sample into a DDT project.  The package file is in the Bin folder of the sample and is named SprocTest.pkg.

Just build this and it will ask you if you want to install the database for the sample when it launches.

...thanks for the diplomatic response!

I've done this quite a few times before without issue so I'm certain that I have something dorked up. For the moment the clock is ticking so I just took conconcurrency off. This is a beta release and not the end of the world. I'll revisit it during a bug fix later next week.

Clay

Ok..I know you are thinking I'm an idiot...but I have gone through this several times end to end and manually compared each step an everything is right. I have done this MANY times with other businesss objects in the past without an issue.

The error I am getting is that the business object cannot find PROSPECT_NAME_ORG. PROSPECT_NAME is the first field in the table and the first parameter in the sproc; therefore, PROSPECT_NAME_ORG is the first _ORG field in the sproc. It seems to me like the .SAVE is not sending along ANY of the _ORG parameters.

Here is what I've done

1. Manually compared all of the fields in my DDT package with the production table and everything is in perfect order and correct down to the field types and sizes
2. Verified that Optimistic All Fields is set in the DDT for my table update.
3. Verified that the _ORG parameters are in the sproc
4. Verified that Optimistic All Fields is set as the Update Concurrency Type for this BO
5. Verified that Update Using Stored Procedure is set to TRUE
6. Rebuilt several times
7. Cleaned the app
8. Deleted the DLLs and rebuilt
9. As a last ditch effort, I have tried running a trace but it is not getting that far so that was a waste of time. 

The sproc has all of the expected _ORG parameters in it, so I am extremely confident that that is not the problem.

Since I have the parameters all checked, I am not sure what to do.

I have also tried the following and IT WORKS

1. Using the DDT, take Optimistic Concurrency off in Table Properties and rebuild the sprocs
2. Refresh the production database with the new sproc that contains not _ORG elements
3. Changed my BO to NOT use optimistic concurrency

That was ALL I did and now I can update records again (without any protection for concurrency issues).

The only thing I can think of Clayton, is that maybe your sprocs were configured to something other than OptimisticAllFields and the business object was configured to OptimisticAllFields.  Your best scenario would be to add a timestamp or row version column and configure both the business object's UpdateConcurrencyType and the concurrency type of the Update stored procedure to the same (either OptimisticTimeStamp or OptimisticRowVersion).

Hi Ben

Please understand that I am not trying to be argumentative but that doesn't make sense. So far I have...

1. Verified that the DDT is using Optimistic Concurrency
2. Verified that the sproc has all of the required fields parameters (2 for each field...one regular/one _ORG). I have manually gone through a printed version of this and checked them off one at a time to make sure that somehow something didnt get lost.

When you read the error, the sproc is not the problem anyway. It is expecting _ORG params and they are NOT being supplied. The .SAVE in the BO is supposed to do the supplying...and the only way I know of to make it do the supplying is to set Optimistic Concurrency in the BO to true (If that is not the case, please let me know).

I have made several changes to the BO (adding and deleting fields) over the last few weeks and the problem did not start until after I had done that.