I am trying to clarify LLBLGen's SaveEntity() behavior (using adapter, v2.0.7.424), since what I have read on the forums, and what my tests tell me, do not always match. Can anybody please review these points, that corresponds to my tests, and sometime contradict the forums:

(for now on, this is about a single entity, so there is no recurse save of any sort)

1.- Calling SaveEntity to save an entity that has been fetched but not modified, will not even trigger an UPDATE and will return true.

2.- Calling SaveEntity to save an entity that has been fetched _and _ modified, will trigger an UPDATE and should return true.

3.- However, if the underlying table row has been deleted in the meantime, an ORMConcurrencyException will be thrown.

4.- Also, if we indicate a predicate, and it is not verified, then an ORMConcurrencyException will be thrown (forums say it returns false?)

5.- The only way we can distinguish between these two cases, is by trying to refetch the entity.

Assuming all these are true, I fail to imagine a case where **SaveEntity ** would return false?

Thanks!

It will return false with an insert which failed, for example when the refetch failed. Inserts don't have concurrency issues, so this doesn't apply to them.

Otis wrote:

It will return false with an insert which failed, for example when the refetch failed. Inserts don't have concurrency issues, so this doesn't apply to them.

Understood.

May I safely assume that my other points are true?

sgay wrote:

Otis wrote:

It will return false with an insert which failed, for example when the refetch failed. Inserts don't have concurrency issues, so this doesn't apply to them.

Understood.

May I safely assume that my other points are true?

Yes . The ormconcurrencyexception is thrown when no rows are affected by the update. So this can be due to the fact that there were no rows anymore, or the filter limited the set to update to 0 rows etc.

Otis wrote:

Yes . The ormconcurrencyexception is thrown when no rows are affected by the update. So this can be due to the fact that there were no rows anymore, or the filter limited the set to update to 0 rows etc.

Great. Thanks, point considered closed!