Thanks Ben

That is what I was afraid you were going to say! I'll just reubild the thing when time permits. For the moment, I'll move on without concurrency and pray for the best!

Well, Clayton, what you have here is a certifiable "gremlin."  You can't find it, but you know it's there

Hi Ben

My responses are below in bold. Thanks for the help. I am completely open to notion that I've screwed something up in this...I am just at a loss as to where to look. My next step is to just build the whole BO from scratch again but don't have time to do that at the moment.

Did you rebuild the partial class for the business object after you added the fields?  There are collections within the partial class that the BO uses when saving the data (that's how it determines what fields to save).  Yes..I tried both Partial and Full rebuilds. Additionally, I have added several fields over the last couple of weeks and these are all available from my business objects as properties. I'd think that this would not be the case if I'd not rebuilt the BOs.

Also, there are 3 different types of optimistic concurrency, OptimisticAllFields, OptimisticTimeStamp, and OptimisticRowVersion.   The UpdateConcurrencyType property on the business object, and the UpdateConcurrencyType of the Sproc (set within the table properties in the DDT) have to match exactly... if the BO thinks it's on row version and the sproc is configured for all fields, then it will throw up. They are both set to OptimisticAllFields. There are 20 or so _ORG parameters in the stored proc. I'd imagine that if TimeStamp or RowVersion were being used, there wouldn't be that many (only one?). 

Also, the properties for your business object can be set within both the component designer for your bo and the property sheet on the individual business object.  Make sure that the property sheet on the instance of the business object is not overriding the property you have set on the component designer. I didn't know you could do this and certainly had not coded it directly...I did check though and didn't find anywhere that was being done in code I had written.

Did you rebuild the partial class for the business object after you added the fields?  There are collections within the partial class that the BO uses when saving the data (that's how it determines what fields to save). 

Also, there are 3 different types of optimistic concurrency, OptimisticAllFields, OptimisticTimeStamp, and OptimisticRowVersion.   The UpdateConcurrencyType property on the business object, and the UpdateConcurrencyType of the Sproc (set within the table properties in the DDT) have to match exactly... if the BO thinks it's on row version and the sproc is configured for all fields, then it will throw up.

Also, the properties for your business object can be set within both the component designer for your bo and the property sheet on the individual business object.  Make sure that the property sheet on the instance of the business object is not overriding the property you have set on the component designer.

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.

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).

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).

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.

...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

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.