{System.NullReferenceException: Object reference not set to an instance of an object.
   at IdeaBlade.EntityModel.NavigationEntityProperty.GetEntityReference(Object entity)
   at IdeaBlade.EntityModel.IdFixupHelper.ValidateTempIds(EntityManager entityManager, IList`1 entityWrappers)
   at IdeaBlade.EntityModel.EntityManager.InitializeWorkStateTempIds(SaveWorkState saveWorkState)}

 

The table has a clustered primary key on two integer columns - the first column is a SQL Identity column which auto-generates a value and the other column is an integer which needs to be set in the application logic.  I'm setting the value required for the second column before saving and assumed the Identity value for the first column would be handled like any other Identity column.  Does this scenario require a custom implementation of IIdGenerator?

 

Thanks for any replies.

No, it doesn't. I did the same test, i.e. saving an entity with a clustered primary key on 2 integer columns (1 identity, 1 set by the client) and did not encounter any exception. Could you provide more info about your entity model? Or if possible, a sample solution?

Also, what version are you using?

 

We confirmed we are able to save a lone entity which contains a clustered key as described in my original post and verified by you.  The actual problem has turned out to occur when there is a child Entity linked back to a parent Entity on the clustered key.  In code we can do everything to create the 2 Entities (initialize, associate, add to EM) however when we save changes the Exception from my original posting is encountered.

Found these steps to actually work:

 

1.) Save the parent Entity with the clustered key which completes fine and returns with the db-generated identity value.

2.) Create the child Entity, associate with the parent, and save.

 

This is clearly not the safe or desired approach as 1 & 2 occur in separate Transactions.

 

I couldn't repro the issue. I did my test with the following:

1. A parent table with a clustered primary key on 2 columns (1 identity, 1 set in the client)

2. A child table with an identity primary key with a clustered foreign key to the parent table described in #1

3. A child table with a clustered primary key on 2 columns (1 identity, 1 set in the client) with a clustered foreign key to the parent table described in #1

In all cases, the save was successful in 1 transaction.

What version are you using? I suspect that you might be using an older version and that the bug has already been fixed.

 

  We are on version 6.0.3.1 which as you indicated is not the latest.  Can you confirm that the issue we are experiencing is a bug which has been fixed since our version? 

Yes, it's confirmed. I ran the exact same tests on 6.0.3.1 and they failed.