Frans,

Is there any way to continue using an entity after it is saved and not refreshed and to avoid the exception that is thrown? Is there exist any property to be set?

entity.Fields.State = EntityState.Fetched;

You really need to do a bunch of things to the entity to make everything work right. After a save, we do the following: 1. Set DBValue to the correct value for every field 2. Set the IsNull for everyfield that got set to Null 3. Set Fields.State = EntityState.Fetched 4. Call Fields.AcceptChanges 5. Set IsNew = False 6. Set IsDirty = False 7. (Probably optional) Call FlagAsSaved

It would be nice if we could just tell LLBLGEN that we don't use DB triggers, and anything saved to the database is just a simple update...so you could just call SaveEntity and the 7 steps above would just happen.

mikeg22 wrote:

You really need to do a bunch of things to the entity to make everything work right. After a save, we do the following: 1. Set DBValue to the correct value for every field 2. Set the IsNull for everyfield that got set to Null 3. Set Fields.State = EntityState.Fetched 4. Call Fields.AcceptChanges 5. Set IsNew = False 6. Set IsDirty = False 7. (Probably optional) Call FlagAsSaved

It would be nice if we could just tell LLBLGEN that we don't use DB triggers, and anything saved to the database is just a simple update...so you could just call SaveEntity and the 7 steps above would just happen.

What you want is only valid after a fetch or better: it's done for you if you set the refetch flag to true. I don't see why that's so much of a problem, as the fetch is very quick: over the same connection, and the same row.

I hate to refetch from a database because of software 'issue'. I have not ran into the problem these guys are having (yet!).

Also, the fetch might involve some prefetches and such - so could be more than one row I guess.

Really liking the product Otis!

Otis wrote:

mikeg22 wrote:

You really need to do a bunch of things to the entity to make everything work right. After a save, we do the following: 1. Set DBValue to the correct value for every field 2. Set the IsNull for everyfield that got set to Null 3. Set Fields.State = EntityState.Fetched 4. Call Fields.AcceptChanges 5. Set IsNew = False 6. Set IsDirty = False 7. (Probably optional) Call FlagAsSaved

It would be nice if we could just tell LLBLGEN that we don't use DB triggers, and anything saved to the database is just a simple update...so you could just call SaveEntity and the 7 steps above would just happen.

What you want is only valid after a fetch or better: it's done for you if you set the refetch flag to true. I don't see why that's so much of a problem, as the fetch is very quick: over the same connection, and the same row.

Its a problem for a couple reasons. First, our fetches are not fast as they go through a stored procedure which performs security filtering, and second, because when we send an object to our server via remoting for an update/insert, we don't remote it back (again for performance). In our particular case, we have to run those 7 steps both in the DAL on update, and on the client side when the remoting call finishes.

We are having a serious discussion right now whether or not to stop using these fetch stored procedures as they are causing nightmare performance problems, as well as severely limiting filtering capability. I personally want to implement our custom security with relations and predicates, but the powers that be like to see an easy to read SQL Profilter line for every DB fetch...not worth the trouble in my opinion, and hopefully the others will see it this way

WayneBrantley wrote:

Also, the fetch might involve some prefetches and such - so could be more than one row I guess.

No, that's not a problem. It only fetches again saved entities, on an entity basis and replaces the data in the same entity object with the data read. This means that if you have an entity which contains other entities and that one is saved, it still contains these entities afterwards.

In selfservicing this is transparent: you save an entity and the first time you access a property of a saved entity, it refetches itself. In adapter, you can control this, if you throw away the entity anyway (e.g.: on a postback in a webpage), refetching it is meaningless of course, hence the flag.

Really liking the product Otis!

I'm glad

mikeg22 wrote:

Otis wrote:

mikeg22 wrote:

You really need to do a bunch of things to the entity to make everything work right. After a save, we do the following: 1. Set DBValue to the correct value for every field 2. Set the IsNull for everyfield that got set to Null 3. Set Fields.State = EntityState.Fetched 4. Call Fields.AcceptChanges 5. Set IsNew = False 6. Set IsDirty = False 7. (Probably optional) Call FlagAsSaved It would be nice if we could just tell LLBLGEN that we don't use DB triggers, and anything saved to the database is just a simple update...so you could just call SaveEntity and the 7 steps above would just happen.

What you want is only valid after a fetch or better: it's done for you if you set the refetch flag to true. I don't see why that's so much of a problem, as the fetch is very quick: over the same connection, and the same row.

Its a problem for a couple reasons. First, our fetches are not fast as they go through a stored procedure which performs security filtering, and second, because when we send an object to our server via remoting for an update/insert, we don't remote it back (again for performance). In our particular case, we have to run those 7 steps both in the DAL on update, and on the client side when the remoting call finishes.

We are having a serious discussion right now whether or not to stop using these fetch stored procedures as they are causing nightmare performance problems, as well as severely limiting filtering capability. I personally want to implement our custom security with relations and predicates, but the powers that be like to see an easy to read SQL Profilter line for every DB fetch...not worth the trouble in my opinion, and hopefully the others will see it this way

I'm sorry to hear that you have this trouble, Mike. I understand after reading this, that simply refetching isn't an option for you.

You can do all the steps in an override of OnSaveEntityComplete, in a subclass of DataAccessAdapter, have you placed that field update code there?

Otis wrote:

mikeg22 wrote:

Otis wrote:

mikeg22 wrote:

You really need to do a bunch of things to the entity to make everything work right. After a save, we do the following: 1. Set DBValue to the correct value for every field 2. Set the IsNull for everyfield that got set to Null 3. Set Fields.State = EntityState.Fetched 4. Call Fields.AcceptChanges 5. Set IsNew = False 6. Set IsDirty = False 7. (Probably optional) Call FlagAsSaved It would be nice if we could just tell LLBLGEN that we don't use DB triggers, and anything saved to the database is just a simple update...so you could just call SaveEntity and the 7 steps above would just happen.

What you want is only valid after a fetch or better: it's done for you if you set the refetch flag to true. I don't see why that's so much of a problem, as the fetch is very quick: over the same connection, and the same row.

Its a problem for a couple reasons. First, our fetches are not fast as they go through a stored procedure which performs security filtering, and second, because when we send an object to our server via remoting for an update/insert, we don't remote it back (again for performance). In our particular case, we have to run those 7 steps both in the DAL on update, and on the client side when the remoting call finishes.

We are having a serious discussion right now whether or not to stop using these fetch stored procedures as they are causing nightmare performance problems, as well as severely limiting filtering capability. I personally want to implement our custom security with relations and predicates, but the powers that be like to see an easy to read SQL Profilter line for every DB fetch...not worth the trouble in my opinion, and hopefully the others will see it this way

I'm sorry to hear that you have this trouble, Mike. I understand after reading this, that simply refetching isn't an option for you.

You can do all the steps in an override of OnSaveEntityComplete, in a subclass of DataAccessAdapter, have you placed that field update code there?

I have placed that code in an intermediate baseclass of Entity that we user (between EntityBase2 and the generated entities). Called the method 'SetCurrentStateAsSaved' and I call it both from OnSaveEntityComplete, and right after the 'SaveEntity' remoting call in our client-side manager 'Save' method.