EntityA has a 1:1 relationship with EntityB.

When using a valid EntityA, you do this:

EntityA.Text="Test"; if (EntityA.EntityB.SomeValue>0) //blah...

(assume EntityBReturnsNewIfNotFound=true)

Now, when you do EntityA.Save(true);

It will attempt to save a related EntityB, when in fact no fields were changed. The 'related field' was changed when you referenced it, but would not need to be saved back out.

Thoughts?

Which entity is PK and which is FK side? (and please use real names) Also, version of llblgen pro, runtime lib build nr would be nice.

They aren't also involved in an inheritance hierarchy by any chance?

EntityA is the PK, EntityB is the FK. Not involved in hierarchy.

Build number - 2.0.0.60826

Would have provided more info, but I thought it was by design.

Here is more information:

I created a View and mapped that view as a table. This view does a sum of some fields with a case statement, etc. I marked the related field as Identity/ReadOnly/Primary key I then mapped that view to a standard Entity.

After referencing that related entity and saving EntityA recursively, I got an error message about not being able to update with aggregates. The only field it was trying to set was the related primary key.

Will use real names next time...let me know if you need anything else.

WayneBrantley wrote:

EntityA is the PK, EntityB is the FK. Not involved in hierarchy.

Build number - 2.0.0.60826

Would have provided more info, but I thought it was by design.

New entities created by the framework because lazy loading returns no result shouldn't be leading to phantom inserts, so they're not set by default as the related entity. Doing string s = myOrder.Customer.CompanyName; shouldn't make Customer suddenly reference a new entity which is inserted when myOrder is saved. This wasn't the case in 1.0.2005.1, and to my knowledge hasn't been changed in 2.0: you explicitly had to set A.B to a new instance if you wanted B to get saved in these situations.

If you set A.B to an instance of B, then it does save B. See below.

Here is more information:

I created a View and mapped that view as a table. This view does a sum of some fields with a case statement, etc. I marked the related field as Identity/ReadOnly/Primary key I then mapped that view to a standard Entity.

Is this A or B? I guess B. A is a normal table?

After referencing that related entity and saving EntityA recursively, I got an error message about not being able to update with aggregates. The only field it was trying to set was the related primary key.

Will use real names next time...let me know if you need anything else.

As B has a pending FK sync, B is saved if the reference is made. This is to be sure entities with an identity PK and just an FK are savable. .

So A is saved, PK is synced with B's FK field, then B is saved. If A.B doesn't point to an entity, it's not there, so in that case B isn't saved.