Bharat_Naik wrote on Apr 7
th, 2011 at 9:07pm:
Already implemented as per Acebanner. It works great. Thank you. Any idea about making log as an alternative? That way one can choose any method they like and still have legal integrity. Requirement is that, whatever changes made has to be listed as what was the original entry and what it has been changed to with date and time and person who made the change.
I personally feel the first method is better for a programmer and less confusing. If still something needs to be rectified, one can add a separate note with date and time.
If I were going to use a log (history) to keep track of any changes to the record, my gut instinct would be to create a subform for the history entries. I don't know the full details, but if these records are of a legal nature, then a subform to hold all the details of the change would be the route I would take. You would need the date of the change, the user who made the change, and the details of the change. What details are likely (or allowed) to be changed? They would be fields in the subform. But then there's the issue of revisions -- do you also need to keep track of the previous version of the document, with the old information, so that an 'undo' could be performed? Makes me twitchy just imagining it!
Yeah, just disallowing any revisions would be a lot easier! Not sure if that's feasible though.
Also ask yourself how often is this sort of revision really likely to be necessary. Why use Thor's hammer to tap in a nail to hold up a picture frame? But even if you do get through by disallowing record modification, you will eventually need to handle how those changes CAN be made. For me and my records/users it's easy -- I can make the changes they have (rarely) wanted to make so I act as the gatekeeper of sorts. But I've only got 3 users, so it's manageable.
The log change subform could work if its kept simple and users realize that if they make a change that
it will be logged. You could require that the reason and nature of the change be supplied by the user before allowing the change. It's sort of a 'locks keep honest men honest' sort of situation. People won't try to make a fraudulent change because they know it will be noted. Also, there's the seriousness of the change. If they just want to change (correct) the spelling of someone's name, maybe that's not worth protecting in this way? Maybe just certain critical fields (Date of Birth, Social Security Number) are protected in this way? A simple history log could work, but I'm not sure how I would implement revisioning. My guess is that would add a lot of overhead to the system for maybe not a lot of payoff.
If you were to attempt revision management of that kind, I would look at the "Push" and "Pop" commands. Maybe the @StringArrayAttributes command could be of use here? Maybe on form entry the values of the critical fields could thrown in a string array, and then checked against it when a record save is attempted? You might be able to throw the old and new values into a set of fields in a subform, along with the date and user. Then if an 'undo' were required you could select the subrecord, hit a command button and the 'old' values would be reinserted. There could be another command button called 'compare' that pops up a WriteLn window for the values that differ. It could loop through both strings and when they differ add to the WriteLn. That way you could see what was changed.
So the user enters a record in Update Mode, and the current values go into the string array.
Then the user tries to leave the record or save it, do a @Modified check, and if there's a change to a critical field pop up a request for a 'NOTE' entry detailing what was changed and why, else move to next record.
If the user made a change and entered the NOTE entry, then allow the save and put in a new subrecord with the USER, NOTE, and the old stringarrayattributes in one field, and then gather up the new stringarrayattributes in a second field.
Table view Subform might look like this, with three subrecords:
1. USER / DATE / NOTE / (HIDDEN ORIGINAL STRINGARRAYATTRIBUTES) / (HIDDEN 'NEW' STRINGARRAYATTRIBUTES)
2. USER / DATE / NOTE / (HIDDEN ORIGINAL STRINGARRAYATTRIBUTES) / (HIDDEN 'NEW' STRINGARRAYATTRIBUTES)
3. USER / DATE / NOTE / (HIDDEN ORIGINAL STRINGARRAYATTRIBUTES) / (HIDDEN 'NEW' STRINGARRAYATTRIBUTES)
I would hide the strings because they might be long, and the typical user wouldn't have to usually see them.
Then have an 'UNDO' and a 'COMPARE' button off to the right of the subform. The 'NOTE' field would be whatever the authorized record modifying user stated as their reason, what was changed, etc. I'm just conjecturing wildly Bharat, not sure if this would work, but that's how I might approach it. Forcing users to leave an audit trail is easy enough; putting the old changes back are a bit harder. Also, I'm not entirely sure if the value of the elements can be saved using the attributes commands. 'VALUE' is listed as an attribute, but I haven't tested it myself. Holy smokes... it might even
work!Good luck Bharat, let me know if it works.