I have a model generated in V3 with the LLBLGen Pro Runtime Framework for a MS-SQL2005 database. In the application I have created several new entities that are related to each other. Also some entities refere to existing entities from the database. The current approach, simplified, I use, is the following:

• save the most unrelated entity with a data adapter, using refetch=true and recursive = false
• because now the entity has a PK value (autonumber) I can use it to assign this entity to the FK of another entity
• save this second entity using reftech=true and recursive = false.

I would like to have these save actions in a transaction. Should I use a transactionscope, pseudocode:

use Transactionscope { prepare entity 1 save entity 1 prepare entity 2 save entity 2 }

or could you do the save with unit of work, or is this a complete wrong usuage of uow:

prepare entity1 uow.Addforsave(entity) prepare entity2 uow.Addforsave(entity) uow.commit(ds)

If I build the related entity's complete in memory and then use a recursive saveaction I end up with some records not related properly.

I would appreciate some advise on a global level for the best approach. Not to global with refering to the manual however

Thanks Piet

You don't have to do the pk - fk management nor the save ordering yourself. Simply assign related entities to eachother (e.g. myEmployee.Manager = myOtherEmployee; ). If they're of the same type, add them to a collection and save the collection recursively, or add all entities to save to a unit of work, and simply commit. The ordering, the Fk syncing, that's all done for you.

Thanks Otis for the reply. I did that in the first place however I ended up with two new user records, one record properly decorated with all FK values and one "zoombie" with only a PK value.

I thought first it was caused by a cyclic reference between customer - portal - user, however removing this field did not help.

I finally found the cause: In a multistep enrollment on a single form for a user, in a previous step I checked if the username was free: I created a local new userentity, filled a unique contraint and checked if the user accountname already was in use. This user entity however, was also saved in the final step.

I succeeded now in using the UnitOfWork in a single statement:

work.AddForSave(customer, exp, true, true);
work.Commit;(ds)

Could use a normal ds.SaveEntity probably also.

Learned that a type with a local scope in a method, if attached to a global entity, escapes from the local scope:

user.Accountname = accountName;
user.Customer = CustomerManager.Instance().CurrentCustomer
ds.FetchEntityUsingUniqueConstraint(user, user.ConstructFilterForUCAccountnameCustomerId());

The user.Customer=... statement "pulled" the variable out of the local scope of the method.

So, it was a bug in me, as usually

Good you figured it out and all is working now