Hi Scott

>I didn't even think about the database backend stuff.  That might be a solution.  I need to learn a lot more about SQL Server.  Heavy use of triggers on a SQL back-end can be a very bad thing. However, this kind of use is precisely the kind of scenario where they make perfect sense. They always fire and they can always be relied on. Also, leaving this kind of thing to the SQL back-end ensures that updates/deletes that happen outside of your application are still recorded. There is nothing worse than a user or customer telling you that your application is in-correctly deleting/updating a record only to find that it is another user in a different application but you are unable to prove it. When you handle this stuff in the database, it fires and therefore does its job no matter who/what is accessing the data. So, in this case, the offending user/application would still get recorded in the audit log. >Thanks for the input. Glad to be of assistance. Best -=Gary

I didn't even think about the database backend stuff.  That might be a solution.  I need to learn a lot more about SQL Server.  Thanks for the input.

Hi Scott

PMFJI - there are obviously many ways that this could be done from within your application. Without knowing too much about your requirement, your post only appears to suggest a requirement for writing a userId value in the BO when the record is about to be Saved. Whilst this would record the "last user", it doesn't tell you too much else. For example, how many times has the record been saved? When did the last recorded user actually save the record? Obviously, from an application standpoint, these points can be addressed in numerous ways.

However, depending on what your data back-end is and your workstation/back-end logon strategy, a fairly typical way of doing this when using something like SQL server is to use triggers. You can record what user table, action (delete/update) and the logged on SQL user in a separate audit table. In fact, this could be the basis of a StrataFrame application-based event log.

In the scenario you outlined, if you write the userId to a record and then delete the record, you no longer have the record to check for the user who actually deleted it.

So, whilst I am not answering your question directly, it might be worth considering these things (relative to the back-end capabilities) and then think about how to implement the strategy from StrataFrame.

HTH

-=Gary

I want to be able to keep track of who adds and deletes a record.  I have added a User BO to the appmain class and can access this from any of my forms.  That is working fine.  What I want to be able to do now is in the before_save event of the BO's be able to assign the value of the user ID to the userID field in the table.

My question here is what is the best, proper, common.... what ever the term is,  method to keep the BO's isolated and able to be used for a web application.  I was thinking of adding a custom property on each BO and calling a custom method of the BO to set the property, or making a public property on the BO that can be set in the Parentform_Loading methd when the BO's are being populated on a form.

Any input would be greatly appreciated. Sorry for the long post but I could think of an easy way to descrip the situation.