Trying to update a record using a stored procedure I recieve the following error:

Trying to update a record I recieve the following error:"Cannot create UPDATE command because a business object with PrimaryKeyIsAutoIncremented = True must have exactly 1 primary key field"

This error makes sense since I have specified two keys for the table I'm updating.  Now I'm not here to discuss the merits of combined keys (not my database design) I'd like to know how to best handle this situation.  If I don't specify both fields as keys then the delete SP call does not send both fields.  If I do set up two keys then I get the above error.  And since the database is most definatly handling the field incrementing turning that off seems a bad idea.  Is there an easy way around this or do I need to go hog tie our DBA?  btw, if it matters this is Oracle (of course).

thanks

Hi Rob,

I presume you know that SF will handle the CRUD without the use of stored procedures. I can imagine this may not be an option for you, i.e. your shop mandates procs, just thought I would mention it.

Cheers, Peter

Yeah, I only wish I could skip the procs for the CRUD. Unfortunately the security bogey man has everyone holding their blankets over their heads. so procs it is.

Additionally, I set the PrimaryKeyIsAutoIncremented property to false, try my update and it errors out because it actually sends the two feilds I set as primary keys twice in the parameters list.  This seems like a bug. 

So to address this I tried including the two fields I set as keys in the FieldsToExcludeFromUpdate list and tried my update again.  This time I get an error about keys not existing in the table.

What am I doing wrong here? 

Rob,

I do not beleive this is a bug, but I never like to rule anything out .  It sounds to me that the sproc is not correct.  Based on this thread alone there is not enough information to diagnose your problem.  The first thing that I would do is turn on debugging for your data source:

This will show you what is being sent via the DAL to the database.  You could then compare this to the actual SPROC to see what is going on.  This is the first place I would look.

One more thing, you may want to look at this post as well: http://forum.strataframe.net/FindPost11014.aspx

Do a search of the forum for Oracle and you will find a lot fo threads where other developers have setup SPs for Oracle which may give you some ideas.

Trent,

I think I've tracked the composite key issue down to BuildUpdateCommand_SP in OracleDataSourceItem.vb

The SqlDataSourceItem.vb version of BuildUpdateCommand_SP has the following logic that I don't see in the Oracle version.

If Not QueryInfo.PrimaryKeyFieldIsAutoInc Then
loParam.ParameterName &= "_ORGPK"
End If

The BuildUpdateCommand_SP is definatly building the SP with two copies of the primary keys when I define more than one in the BOM.  One copy each for the values contained in the QueryInfo.Fields collection and one for the values QueryInfo.PrimaryKeyFields collection.

I'll build you an example project if you'd like.

Trent or Ben,



I was wondering if anyone has had a chance to look at this yet, and when or if I should expect a fix? I have some other people that are relying on this piece and I need to decide on building a workaround or not.



Thanks for your help.

Yes, we are working on it.  I'll keep you posted as to what we find.

Looking through our unit tests, everything is working as it should.  Could you post the .designer.cs (.vb?) file for the business object that is causing you the problems? 

I'm thinking it has something to do with the PrimaryKeyFields property because the first iteration of the BuildUpdateCommand_SP should not include the PK fields, so they shouldn't be added twice.