Also, in your AppMain.vb, at the bottom of the SetDataSources() method, you can call this:

DataBasics.DataSources("").SetDebugOn("C:\Debug.html", True)

This will turn debugging on on your data source and create that Debug.html file containing a list of the DbCommands that were executed against the data source.  It will list off all of the parameters, so, you can get a better picture of what the business object is expecting for the signsture of the stored procedure.

I believe it will also automatically show the debug file when the application exits it it exits logically.

The business object is expecting a certain structure for the stored procedures.  The structure depends upon the UpdateConcurrencyType that you have configured.  In the DDT help file, under Tables -> Table CRUD Stored Procedures, you will find examples of the stored procedures that the business object is expecting.  Most likely, you still have the UpdateConcurrencyType set to OptimisticAllFields, which is the default.  If that is the case, the business object is expecting to send all of the fields twice so that it can check the concurrency before it does the actual update.  Your best bet is going to be to set the concurrency to OptimisticRowVersion, which means you will need to add a row version column to your table or just set the concurrency to Off, which won't send any extra fields in the update.

Its a sproc I created. What would be the difference?

is this a stored procedure that you created, or is it one that the DDT created?

When I try a SAVE() based on an Edit , I get

"MicroFour.StrataFrame.Data.DataLayerSavingException: Procedure or function cp_employee_upd has too many arguments specified

I have checked and the number of fields that my business object has is the same as the sproc requires. I have tried commenting out all but one of the parameters (there are 38 actual ones including the primary key) but still get the same error.

The code looks like this

• bo.FillByEmployeeID(intEmployeeID)
• bo.FIeld1 = "X"
• bo.Field2 = "y"
• bo.Save()

Thanks much!

Yes, those will all work.  However, the semantics might be a little different.  When you have a UI and controls bound to a business object, you usually use Add(), Edit(), and DeleteCurrentRow().  However, if you're just modifying records programmatically, you can use NewRow(), [nothing] (since you can just change fields without calling Edit()) and DeleteByPrimaryKey as they are slightly faster since they circumvent the UI.

Ok...I think I have this straight.

To do an update would look something likethis

• dim t as bo
• bo.fill... (I would fill my Primary Key)
• bo.edit
• bo.field1 = "X"
• bo.save()

To do an insert would be

• dim t as bo
• bo.add
• bo.field1 = "Y"
• bo.save()

To do a delete would be

• dim t as bo
• bo.deletebyprimarykey(z)

It uses the sproc if the DeleteUsingStoredProcedure property is set to True, same as a Save() with Deleted rows.

Does DeleteByPrimaryKey use the sproc listed under DeleteStoredProcedureName or does the user have to have db_writer priveledges?