Print Page | Close Window

New error saving Entities

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1961
Printed Date: 23-Apr-2025 at 10:13am


Topic: New error saving Entities
Posted By: dkearney1
Subject: New error saving Entities
Date Posted: 13-Jul-2010 at 9:10am
We recently updated from v3.6.4.1 to v3.6.10.0, and are now encountering a frustrating, intermittent error. The error is IdeaBlade.Persistence.PersistenceManagerSaveException: Save failed - The INSERT statement conflicted with the FOREIGN KEY constraint "FK_BillLineItemExtension_BillLineItem". It appears that the "child" (BillLineItemExtension) record is being INSERTed prior to the "parent" (BillLineItem) record.

I've verified the following:
  • The entities are being created and added to the PersistenceManager in the correct order
  • The code hasn't changed in several years
  • Retrying the specific bill without changes to the code or the bill results in a successful save.

The error is not specific to the BillLineItem - BillLineItemExtension entities/tables, there are several parent/child scenarios that will intermittently demonstrate the problem. This is just the one I picked to put in the post.

Any ideas?

Thanks,
Dan

-------------
Dan
“In anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take away.”
Saint-Exupéry
Wind, Sand, and Stars


Replies:
Posted By: dkearney1
Date Posted: 14-Jul-2010 at 1:29pm
Are the "Classic" boards still being monitored by IdeaBlade folks?

-------------
Dan
“In anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take away.”
Saint-Exupéry
Wind, Sand, and Stars

Posted By: ting
Date Posted: 14-Jul-2010 at 6:24pm
Yes we are.  See the "Persistence Order" section of the Developers Guide.  You have the option to specify the save order if the system cannot reliably figure it out for you.

Posted By: dkearney1
Date Posted: 15-Jul-2010 at 6:05am
RTFM? Gotcha, will do.

-------------
Dan
“In anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take away.”
Saint-Exupéry
Wind, Sand, and Stars

Posted By: dkearney1
Date Posted: 15-Jul-2010 at 10:21am
I'm attempting the workaround you directed me to, but it just seems to be pushing the problem around. I created the following list of 4 types:
  • BillHeader
  • BillHeaderExtension
  • BillLineItem
  • BillLineItemExtension
and set them into the PersistenceManager's DefaultSaveOptions.PersistenceOrder. The effect of the change was immediate, any transaction involving any of the 4 types began to fail, but with other "save order" related errors. I tried adding more types to the list, and each time I did, those items would no longer be the source an error, but others would.

Am I going to have to define the save order for each entity in my model?

-------------
Dan
“In anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take away.”
Saint-Exupéry
Wind, Sand, and Stars

Posted By: ting
Date Posted: 15-Jul-2010 at 5:19pm
A few notes (you can find these in the API reference for PersistenceOrder):
 
Any entity types that are not specified will be treated as if appearing after the specified types.
 
Processing of a save operation will be handled internally in the following sequence:
1)  First all deletes for all tables will be processed in the inverse order to that specified by the PersistenceOrder.
2)  Next inserts and updates will be processed in the specified PersistenceOrder.
Manually specifying the order for all types is a hassle, as you noted.  You can call get on PersistenceOrder to get the default ordering of types first, then move the few that are problematic to the correct location, and finally call set on PersistenceOrder to use the corrected ordering.
 
We didn't appear to change the code in the area from v3.6.4.1 to v3.6.10.0, so I'm not sure why this is showing up now.  If you made schema/relationship changes/additions to other areas, it's possible that the graph is complex enough or has a circularity that DevForce is having trouble resolving it.
 

Posted By: dkearney1
Date Posted: 16-Jul-2010 at 9:28am
I'll review the schema changes in other areas that were made before the version upgrade to see what was introduced. Are there specific patterns, other than the circularity you mentioned, that you know to be "complex"? I have about 430 entities defined in my Model, does size affect complexity? Anything else you can think of to look for?

-------------
Dan
“In anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take away.”
Saint-Exupéry
Wind, Sand, and Stars

Posted By: ting
Date Posted: 20-Jul-2010 at 4:16pm

There might be difficulty when there are large graphs with multiple paths between two objects although it *should* be able to figure that out.  Other dependencies that DevForce is not aware of could also cause problems (e.g. triggers).


Print Page | Close Window