I turned this on for all my BO's in an old project. When I go to update now I get the error that the update sproc tablename_UPDATE has provided too many parameters. The spoc on the server has a parameter count equal to the field count in the table. When I turn on debugging for the datasource I see it passing double the amount or parameters, one for easch field and one for each field with "_ORG" addd to the end?

Expected behavior? I have been working with DB2 so I dont have a lot of expereince using sprocs for my CRUD, I have it working but had to set the UpdateUsingStoredProcedures property back to false on the BO.

This was a small app that has to now grow so I think using CRUD sprocs is best, so I need to work this out.

Keith Chisarik

The _ORG parameters are expected when you have the Concurrency set to OptimisticAllFields instead of a row version.  Really you always want to use RowVersion over OptimisticAllFields anyway...WAY faster!  The problem is that your sprocs do not have the _ORG parms that would be required to use the OptimisticAllFields.  So do three things:

1. If you don't have a row version field, create one (an integer field) for the table
2. Update the CRUD settings on the BO to use RowVersion and then supply the RowVersionOrTimeStamp property with the field name of the row version field in the table.
3. If you are using the DDT, update the table properties to use the Row Version as well...but if you are using DB2, you will have to manually update the sprocs.  There is a help topic that shows how to create and structure these CRUD sprocs.

Im using DDT and have had it set to OptomisticRow version from the start, all my tables are built with this as the default for SQL server. So somewhere, something thinks I am using OptomisticAllRows? Any idea what that might be?

Keith Chisarik

Let's take one table and view it from both the DDT and BO settings.  First, if you open the table properties within the DDT, it will look like this:

Next, the CRUD settings on the BO will need to match.  If you are using the standard DDT naming convention (as shown above: TableName_Update, for example), then you will not have to supply the sproc name on the BO, but if it is a custom name or varies in any way from that naming convention, then you will have to supply the name on the BO.  In this example, we are following the standards and do not need to supply the names on the BO, just indicate that we want to use the sprocs:

That is basically it.  If you still get errors, then open up your sprocs (through SQL Server Management Studio) and make sure that they are being deployed.

got it, I had a BO instance on a form that didnt have the properties inherited right.

Keith Chisarik