I have an entity of type TransferEntity and it has NominalTransaction and NominalTransactionID properties.

I do not fetch the NominalTransaction on a prefetch and so that is null and NominalTransactionID is set to 2537. All as expected.

If I now set a NominalTransaction via either transferItem.NominalTransaction = myNewNominalTransaction; or myNewNominalTransaction.Transfer = transferItem;

then I the old NominalTransactionID stays as-is.

Is this the expected behaviour?

Which LLBLGen runtime library version (build no.) are you using?

v3.5.12.0712

I see that the involved relation is 1:1. What is the pk/fk side? Please describe the relation between them. Is the FK field also a primary key?

daelmo wrote:

I see that the involved relation is 1:1. What is the pk/fk side? Please describe the relation between them. Is the FK field also a primary key?

Sorry, forgot to reply to this!

Basically AccountsTransaction 1 : 0..1 NominalTransaction but I've attached a screenshot of the relationship to be clearer.

There is a checkbox which says "'AccountsTransaction' is Primary Key side. This is unchecked - I can't remember why specifically but I think it didn't work if checked.

The reason we did it this way is that an AccountsTransaction can existing without a NominalTransaction but not the other way around.

What the relation between the TransferEntity in the first post with the AccountsTransaction in the last post?

Walaa wrote:

What the relation between the TransferEntity in the first post with the AccountsTransaction in the last post?

Yes, sorry - the 'TransferEntity' has been renamed to AccountsTransaction.

Don't think its relevant but just in case: AccountsTransaction is the root of a Target per entity hierarchy with currently four descendents.

So, TransferEntity is not part of any inheritance hierarchy? Could you please post you .llblgenproj file? You can include just the relevant entities if you want. You can do it in the HelpDesk forum, which is private.

Blimey! Forgot all about this issue until it just bit me again.

The LLBLGen project file should be available in the private area in another query. If not, move this there and I'll post it up.

The problem is this line which is part of the save routine for a FeeInvoice:-

feeInvoice.NominalTransaction = feeInvoice.CreatePosting();

CreatePosting() will always return a new NominalTransactionEntity or null.

In this scenario, just before the above line is called:- feeInvoice.NominalTransaction is null (because it isn't part of the prefetch). feeInvoice.NominalTransactionID (int?) is set to 2698.

The above line does not set feeInvoice.NominalTransactionID to null, it stays at 2698. LLBLGen therefore sees no change and no change is made to NominalTransactionID in the database. So when I subsequently delete NominalTransaction with ID=2698, it blows up with a Foreign Key exception.

So the problem seems to be that when a related entity property is not prefetched, it cannot be set to null to remove any existing related entity.

Is this the expected behaviour?

We need more info about the inheritance hierarchy, especially if AccountTransaction and NominalTransaction are in it (so let it be the .llblgenproj file with just the relevant entities involved). Also the real code and the generated SQL for that code.

Maybe it's better if you open a new HelpDesk thread.

Reproduced with the following code:

var prod = new ProductEntity(1);
using (var adapter = new DataAccessAdapter())
{
    adapter.FetchEntity(prod);
}

prod.Category = null;  // prod.Category is already null

Debug.Assert(prod.CategoryId == null);

The thing is prod.Category is already null, so attemting to re-set it to null is not detected at this stage.