I'd like to know how to determine success on a commit in a datascope when this doesn't have any changes. The following scenario:

1 access database with mutations (stock mutations) 1 different access database with aggregates (products)

Mutations are read if they have not been succesfully processed before (processed==false) some mutations lead to changes within an aggregate and some do not. Now I want to read in all non-processed mutations, update associated aggregates, and first commit the aggregates, and then commit the mutations. But sometimes the aggregates dont get updated because some mutations don't lead to a change in stock (field in the product aggregate). Now I could leave this as is, but then the count of these 'non' mutations would increase dramatically and would everytime be read. I'd like to set them to Processed=True. Changing the order of commits (first mutations, then aggregates or first aggregates then mutations) doesn't change the outcome of the commit on no changes in the aggregates. I would like to know if there is an easy way (or another way) to determine success on commit when there are no changes (or determine no changes just before commit, because that is also 'success' for me).

Please post a simple code snippet that represents the behavior. Also post additional info: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7718

That behavior is stated in the documentation. I want to know what would be the strategy to solve my scenario.

http://www.llblgen.com/documentation/5.0/ReferenceManuals/LLBLGenProRTF/html/FA57AC10.htm

DataScope.CommitChanges Method (ITransactionController) ... Return Value Type: Boolean true, if 1 or more actions were performed by the unit of work, false otherwise

Bind an event handler to http://www.llblgen.com/Documentation/5.0/ReferenceManuals/LLBLGenProRTF/html/2D0C40C7.htm

When an entity has changed, you'll get the event, and you can then decide what to do with it, e.g. set a flag or other things. If you don't get the event, nothing changed.

Thanks for your answer. I have a bit of a problem with that. Often in a business process I ask some service to process mutations and receive a changed set, then in that same business process another service call, and then finally save these in a transaction. So I do have the entities, but they already COULD have changed (not necessarily) before I attach them to the DataScope. Then I don't get this Event handler to trigger...

Ideally I'd like to ask the DataScope.HasChanges? I guess you are already walking through an internal list of attached entities. But this list is internal so I can't use it. Maybe you could build this boolean?

The event handler I mentioned is triggered by an event in the entities. So indeed, if they're already changed, this won't happen when you attach them.

But back to the original question. Looking at the code, DataScope.CommitChanges returns true if UnitOfWork.Commit() returned 1 or higher. If 0 actions took place, Commit will return 0 so CommitChanges should return false. So I don't see how it could return true while nothing was done by the unit of work. Do you see it return true even though nothing was done?

No it does return false when there are no changes in the attached entities. As expected.

The two UoW are in one (system)transaction. When one of them fails (that is, a change cannot be committed) the other one must also be rolled back. If one has no changes, that would be alright for the other one to commit. Now I cannot determine if the one without changes is a success for the whole transaction to reliably commit. If I would somehow know that a DataScope has no changes, I would not commit that one in the system transaction.

Maybe I can rely on ORMQueryExecutionException when an error occurs? In that case the return value True of False does not matter at all or am I wrong here?

CommitChanges either returns or it throws an exception. If it doesn't throw an exception, nothing went wrong and you check the return parameter if something was done. If an exception occurred, something was wrong and you have to roll back the transaction, if it is in an ambient one.

So as far as I understand your situation, you just use a try/catch and roll back in the catch clause and ignore whatever commitchanges returns as you only have to roll back if an exception occurs.

Sorry for my misconception here. That's ofcourse the solution. Thank you for your patience.