>>Tim
>
>Originally I was planning on saving the changes in a separate table as I thought it was just an audit trail needed, but it definitely makes more sense keeping the changes/history in one table.
>
>I'm afraid that I need a bit more help with the specifics.
>
>When you say "do that on the retrieval", what method would you suggest? I was thinking the HookPostGetEvent() would be ideal, but what code do I use in there to create the new entity and return that instead of the one that has already been created?
>
>Whether or not they save the new record should have no effect on the original record.
>
>With respect to what I tried that didn't work, can you explain why it didn't? I had used this code:
>
>

        protected override void HookPostGetEntity(PolicyEntity policyEntity)
>        {
>            // check if the entity's status is not "Pending"
>            if (policyEntity.StatusFK != (int)StatusCode.Pending)
>            {
>                // if so, then convert the entity to be a "new" record
>                this.CallStateChange(mmBusinessState.Adding);
>                policyEntity.PolicyPK = Guid.NewGuid();
>            }
>        }

>
>then when I saved I got a message about the update statement not affecting any of the expected rows. If I had changed the state to Adding, why was it doing an update and not an Insert?

Hi Frank,

What is wrong with putting this in your main retrieval method? Do you have a public method that you are calling on your business object to get the specified policy? That method could be self contained with getting the specified entity, checking the status, then creating a new entity with the changes you need and returning it instead. There is no need to use a hook method when you are calling some method to retrieve the entity in the first place. This would work best because you are retrieving a new entity, setting the values and then *It* is the current entity on the business object so you can bind to it normally and save it normally.
Tim