This exception is being raised when I try looking at a property after a executing a SaveEntity call using adapter:

if((_fields.State==EntityState.OutOfSync)&&!_fields[fieldIndex].IsPrimaryKey)
{
                throw new ORMEntityOutOfSyncException("The entity is out of sync with its data in the database. Refetch this entity before using this in-memory instance.");
}

Inside SaveEntity, the state is being set to OutOfSync right after the save takes place (if it was successfull). Am I missing something?

Yes, as soon as you save it, it's considered out of date. Refetch it. There's a version of SaveEntity that takes a flag to fetch it.

Frans has a couple of threads on here where he explains why he does this.

JimFoye wrote:

Yes, as soon as you save it, it's considered out of date. Refetch it. There's a version of SaveEntity that takes a flag to fetch it.

Frans has a couple of threads on here where he explains why he does this.

Hmmm...but opting to not refetch after the save still leaves the entity outofsync, making access to the properties impossible. Why is outofsync set when refetchaftersave = false? I see the argument Frans gives that triggers may have changed the state of the data, but we don't use triggers in this way in our database...If you select not to refetch, shouldn't the state be kept as "in sync"?

mikeg22 wrote:

JimFoye wrote:

Yes, as soon as you save it, it's considered out of date. Refetch it. There's a version of SaveEntity that takes a flag to fetch it.

Frans has a couple of threads on here where he explains why he does this.

Hmmm...but opting to not refetch after the save still leaves the entity outofsync, making access to the properties impossible. Why is outofsync set when refetchaftersave = false? I see the argument Frans gives that triggers may have changed the state of the data, but we don't use triggers in this way in our database...If you select not to refetch, shouldn't the state be kept as "in sync"?

If you set refetch to true and it still is outofsync, the save didn't succeed or the refetch didn't succeed and SaveEntity returned false. Please check that. It can be you save an entity with an identity pk, but the table isn't set for an identity pk for example, so the PK becomes '0' (this is an example) and refetching it will of course not succeed.

It's marked 'out-of-sync', because by definition, the entity's data can be updated by triggers AND default constaints for example. So after a save action, if you want to work on the entity in memory again, you have to refetch it.

This isn't done by default, to save performance in the scenario's where you don't need the refetch. In the scenario you're in, you need hte refetch so please set the refetch parameter to true.

Otis wrote:

mikeg22 wrote:

JimFoye wrote:

Yes, as soon as you save it, it's considered out of date. Refetch it. There's a version of SaveEntity that takes a flag to fetch it.

Frans has a couple of threads on here where he explains why he does this.

Hmmm...but opting to not refetch after the save still leaves the entity outofsync, making access to the properties impossible. Why is outofsync set when refetchaftersave = false? I see the argument Frans gives that triggers may have changed the state of the data, but we don't use triggers in this way in our database...If you select not to refetch, shouldn't the state be kept as "in sync"?

If you set refetch to true and it still is outofsync, the save didn't succeed or the refetch didn't succeed and SaveEntity returned false. Please check that. It can be you save an entity with an identity pk, but the table isn't set for an identity pk for example, so the PK becomes '0' (this is an example) and refetching it will of course not succeed.

It's marked 'out-of-sync', because by definition, the entity's data can be updated by triggers AND default constaints for example. So after a save action, if you want to work on the entity in memory again, you have to refetch it.

This isn't done by default, to save performance in the scenario's where you don't need the refetch. In the scenario you're in, you need hte refetch so please set the refetch parameter to true.

We implement defaults on the client-side so we don't have to worry about default values and we use business rules to enforce constraints (also client-side). The triggers we use are limited to affecting the scope outside of the entity graph we are saving. We do it this way specifically so we don't have to refetch data on every update. In our situation, do you see any problem with setting EntityState to "Fetched" on successfully saved entities? We are doing this right now outside of the dataaccessadapterbase2 code so that we can continue working on the entities...

There's no problem with setting the status to Fetched, as long as you first check what the save result was prior to setting the status to Fetched. For example, if SaveEntity() returned false, the save failed, so setting the status to Fetched would be wrong.

Otis wrote:

There's no problem with setting the status to Fetched, as long as you first check what the save result was prior to setting the status to Fetched. For example, if SaveEntity() returned false, the save failed, so setting the status to Fetched would be wrong.

Ok, thanks for the help