>Hold on here, lets figure out what kind of state we're trying to preserve. If all you are trying to do is prevent an update conflict, this can be handled with a timestamp.

Yes, makes things much simpler.

>There should be no need to preserve data state like you are contemplating. There are lots of things that do require that state be saved, but this state is usually tied to a session. This can be handled with a custom state object, and persisted to a memo in a session table with wwXML's ObjectToXML method, and retrieved using its counterpart XMLToObject method. Using these, you are not limited to the number of variables (Properties) you can save, but I think the sort of state you are trying to preserve indicated that you are on the wrong track.
>
>Properties like fOEF and AllowDeletes have no business in a stateless business object, except for use internally. What sort of UI are you going to have that will allow or disallow deletes from session to session, and require that the business object keep track of it? This sounds like more of a use for a user table/object that holds rights for specific users.

I want to understand what I need to do to make the transition into stateless COM objects for my business classes. There are many situations where an lAllowInsert, lAllowDelete, or lAllowUpdate are predicated on the evaluation of business rules separate from user specific rights. Currently, they are exposed as public and used both internally and externally. While a UI can always allow a user to attempt an Insert and then provide a "no-can-do" message only after the business object's Insert business rule fails, it is preferable that the UI not allow it in the first place.

I have to admit I'm kinda slow in grasping some of this stuff. It will probably come to me the same as OOP - frustration... more frustration ... then BAM like a bolt of lightening.