Hello,

Just to make sure I understand well...

I think I red that objects are processed in the following order in transactions: 1 - Added object 2 - Modified objects 3 - Deleted objects

Am I right ? Or query are built on each actions and processed in order they where made in code. I mean...

On a relation m-n. If I delete the relation between x and y object, then create a relation between x and y if it does not exists, all of that in the same transaction. What will I have at the end... 1 or 0 relation between x and y ?

Thanks

I don't know the default order off hand, but as an alternative, if you want to control the order of operations you can use a Unit of work

            var commitOrder = new List<UnitOfWorkBlockType>();

            commitOrder.Add(UnitOfWorkBlockType.Deletes);
            commitOrder.Add(UnitOfWorkBlockType.Inserts);
            commitOrder.Add(UnitOfWorkBlockType.Updates);

            UnitOfWork2 unitOfWork = new UnitOfWork2(commitOrder);

You can also see the help document under Generated code - Unit of work and field data versioning, Adapter for some more information.

Thank you for the information lethologica ! It will be probably very usefull in the future.

But I still want to elucidate the normal behavior of transaction. I have weird behavior but before investigate too much time of debugging I would like to know if transaction does not respect order we program in code... That would explain my actual problem !

If normal transaction sequences of actions would always do: add, modify then delete, it would explain everything.

I think I red that objects are processed in the following order in transactions: 1 - Added object 2 - Modified objects 3 - Deleted objects

That's the default behaviour of executions of the UnitOfWork actions. Which is controllabale by the way.

On the other hand Transactions respect the order in code.

Hello Walaa,

Thanks a lot for the information. I probably have a bug in my code but I continue to suspect a little bit LLBLGEn. I tried to download adventurework sample database to reproduce the bug on a database you can have. I met few problems that I don't really have time now to search and fix. Since the beginning of the day I had 3 more urgent things to do in my stack. If I could find the time soon, I will make the test and get back to you to tell what's my bug (because it is highly probable that the fault is at 18 inches of my monitor.

Thanks for the information.

(You can consider this as close and I will re-open it when time will enable me to do it).

Hi Wally,

Also, when Deleting - Please make sure you are adding Entities to be deleted to the Unit Of Work in the proper order. Delete Children, then Parents. Otherwise, you may be deleting a Parent before deleting its Child - which will throw an SQL dependency error.

Ryan

Hello rdHatch,

Thanks for the info. I'm not sure that will apply because we almost use everywhere cascade delete. Just as info, I do not use unit of work actually. I use plain transaction because I want action to be executed in the exact order I program them in code.

Just as more info...

Note: "relation entity" is the entity where reside the relation between 2 entites in a relation m:n.

The problem I have is part of a silly behavior I have to do to meet my customer requirements...

I have to re-do relations on 2 entities in a relation m-n. I delete each relations between the 2 entitites then I reconstruct relations accordingly to the new states of both entities. The problem seems that delete never occurs in first step althought I put my relation entity in the transaction and delete it. Relation entities stay there and at the final result I have the relation defined twice. I made 2 things: - ensure to never have 2 times the same relation by adding an integrity constrain. - adding more code to not trying to delete the relation entity if I should reconstruct it

The other thing I didn't verify (and I should do) is that probably that I never delete any relation entity and have non coherent database (too much relations between objects).

Thanks for your support.