Saving foreign key error

Hello,

I have a test case in which I am testing to ensure that my object saves correctly that is bound to a one-to-one relationship:

var object1 = new Object1();
var object2 = new Object2(object1); //Internally this sets the EntityHolder to point to the first object
object2.Save(); //This encapsulates retrieving the UnitOfWork (per thread) and saving the associated items to the database

This works perfectly in my Test projects without any problems (note that I am using the Lightspeed trial running with the nightly build). The same code has been inputted into my application and at run time I get the following error:

VistaDB.Diagnostic.VistaDBException (0x000000FA): 
Error 170 (Provider v. 4.3.3.34): Expression statement failed  
Error 172 (Provider v. 4.3.3.34): Cannot pass constraint:  FOREIGN KEY REFERENCES ( 'Object2' )
Error 341 (Provider v. 4.3.3.34): Cannot execute script after inserting a new row 
Error 250 (Provider v. 4.3.3.34): Cannot create row:  
Table: 'Object1', RowId = 1

I originally got this error when I tried saving object1 before saving object 2 (before finding out that the above solution works:

var object1 = new Object1();
object1.Save();
var object2 = new Object2(object1);
object2.Save(); 

I am baffled by this problem I debugged each case and they seem to function in the same way but in the second instance the error always appears. Any ideas? Thanks.

Check which table holds the FK in your test database vs production. In a 1-1 relationship we create the database table with one side holding the FK, so the insert order will matter here. Also try capturing the SQL statements that are being generated by attaching a Logger to the LightSpeedContext and verify that you are seeing the same ordering to the insert statements between your tests and production.

Jeremy

Correction: The test project has:

var object1 = new Object1();
var object2 = new Object2(object1); 
object1.ListOfObject3.Add(new Object3());
object2.Save();

So the difference is that I am manipulating an internal list of Object1 before saving the Object2. Is this a bug, maybe an issue with the properties not notifying?

So it seems when I do the latter, by looking at the logs, Object2 is inserted before Object1 however when I try the initial code snippet it tries to insert Object1 first before Object2. What would cause this behavior?

This would ordinarily happen if Object1 has a dependancy on Object2 as we sort the entity types into the dependancy hierarchy for insert. Is the FK defined on Object1 or Object2 in the 1 to 1 relationship?

Jeremy

It is defined on Object1.

Any ideas?

The discrepancy in the sort order is odd and given the FK defined on Object1 referencing Object2 I would expect Object2 to be inserted first and then Object1 so something much be changing this order in your initial case although its not evident what so we will need to try and reproduce this locally to dig into this further.

Can you please send us through a small repro project based on your model which triggers this behaviour and we can have a look into what is occurring and look into a fix.

Thanks!
Jeremy

I can not reproduce it in the sample project I built. I am going to dig deeper into the other model to see what could be causing the issue. I am do extra processing when an object is saved/deleted so that may be having an effect on it.

Hi Greg,

Thanks for sending through the repro. The issue you are seeing is actually a previously seen issue when using Class Table Inheritance where the ordering of the dependancies when an association is defined on the base class. We have added a candidate fix for this, so to apply this you need to enable a compatibility flag on the context which switches the logic we use for ordering tables which will then generate the correct insert order.

You want to apply the EnableCandidateFixes option for the CompatibilityOptions property on your context.

Here is an example of how to apply this:

Context = new LightSpeedContext<ModelUnitOfWork>
{
        ConnectionString = "",
        DataProvider = DataProvider.VistaDB4,
        Logger = new ConsoleLogger(),
        VerboseLogging = true,
        CompatibilityOptions = LightSpeedCompatibilityOptions.EnableCandidateFixes
};

Jeremy

Thanks that works great! Is there any ETA when this will be released officially?

Not as of yet, we probably wont switch this over for 5 but will look at doing something for a later 5.x release. For now you will want to use this via the CompatibilityOption. We will make a blog post about this when we switch this over.

Jeremy

Just a note, I also ran into this tonight and the compatibility fix appears to be good. Is there anything else I should know that I'm turning on with this flag?

Currently that flag only impacts the CTI behavior you are currently using it for and a change to BeginEdit which will prevent it from traversing lazy associations (see: http://www.mindscapehq.com/forums/thread/1566549 for details)

Jeremy