>>>>
>>>>Hi Linda,
>>>>
>>>>I did not get any other message from you besides this one, so no problem.
>>>>
>>>>I would prefer to not do this at the point of saving, as it just doesn't seem right to me. One of the other complications I foresee is if the save does not work, due to some business rule failing, then I'll have to track the fact that I've already copied the old entity to a new entity and not do it again. Whereas, if I do it at the point of getting the entity, I should be able to just substitute the old entity with the new one and then everything else should just work. I was looking at HookPostGetEntity(), but what I tried does not work (just switching the state to Adding).
>>>>
>>>>If I could trap the fact that the status is Pending, then create a new entity, copy the data from the old entity to the new one and return the new entity, that would work too, but I don't know how to do that in MM.NET.
>>>
>>>
>>>That would be a simple way to do it Frank.
>>>
>>>Retrieve your entity into a local entity object and check the status
>>>PolicyEntity entityOriginal = this.GetEntity(get your initial entity)
>>>if status = "whatever"
>>>PolicyEntity entityNew = this.NewEntity()
>>>entityNew.field1 = entityOriginal.field1;
>>>etc.
>>>
>>>If your method returns an entity object then just return the entityNew when you are done.
>>>
>>>I would probably extract my copy stuff into a separate method in your biz obj to copy all the properties over. I am sure with some effort you could do this by looping through all the properties making it a bit more generic. Then just change the ones you need like status to what you need.
>>>Tim
>>
>>Where would you suggest being a good place to do this Tim? Have you read through all the other posts in this thread?
>
>Yes, I have Frank. Based on how you are doing this, I think it makes sense to put this in your retrieval method as you suggested. On the other hand, I might have done that differently anyway. You indicated you are creating a new record so you have a history. I wonder if it makes sense to capture the history to a different history table (just the parts you need for the history) while keeping the existing live record able to change state. None the less, that is for you to decide as you know the requirements and I am not intending to second guess your intentions.
>If you need to automatically create a new record based on the status, then I would do that on the retrieval. The only problem is if they don't save that record is there any effect on the original record? I would put all that in my business object as it has nothing to do with the UI. I hope that answered your question.
>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?