For medico-legal purpose I need to make certain that the record cannot be changed after the day of preparation.  I have placed the following code in Form Exit Event

vMaxDate = @xLookupR (@FN, "9999/12/31", "Physical!Date1", "Date1")

//WriteLN ( "MaxDate = " + @str (vMaxDate)) - above to prevent manipulation by changing system date

//date1 = date of preparation of record

If @Mode () = 1 and (@Date > Date1 or vMaxdate > Date1) and @Modified = 1  then
     {
           Notifyform (1)
           @msgbox ("The record cannot be changed for Legal Integrity Issue", "The change made in the record will not be saved", "Please Add a note using NOTE form if you need to")

     }
     Else
     {

           Notifyform (-1)
     }

Form Exit Event is almost synonymous here even though technically it is not as you can be on the same form using formcommit ( ) or @Save command without exiting the form.

This seems to work but I believe there might be a better way, such as,  inform the person immediately on changing any part of the record instead of waiting till the end when he/she tries to save the record. Your feedback and help is very much appreciated.

Also I have other option to prepare the log of changes made in the record using date and time of change. Any ideas on easy way to accomplish that?  

Minor edit to my programming posted above. I neglected to include a chunk of programming at the very top that allows for some fields to be excluded from becoming ReadOnly.

Sorry!   What follows is the complete programming.

//Use On Form Entry to set all elements to Read only (not grey) for
//Records before the closing date

vExemptFields = "JOBNUMBER;CLIENTNUMBER;MJOBNUMBER;ESTIMATENUMBER;ENTRYDATE;CANCELLED;COMPLETE;JobMethods;InvoiceNumber;InvoiceAmount;REP;COMPLETEDATE" // List all the existing RO fields that should be exempt.
vElements = @DifferenceStringArray(@StringArrayElementList(), vExemptFields) //get list of all elements on form

vCnt = @CountStringArray(vElements) //count how many there are

//check if record date is ok
If (ENTRYDATE <= @ToDate(@GlobalValue("gvCloseDate"))) AND (@MODE() = 1)
{
	Visibility(ClosedNotice, 1)
	If @UserID <> "Admin"
	{
		vLoop = 0
		While vLoop < vCnt // loop through all elements and set them RO
		{
			vLoop = vLoop + 1
			vName = @AccessStringArray(vElements, vLoop)
			SetThisElement(vName)
			vNN = @ElementType(ThisElement)
			If (vNN > 999 and vNN < 1009) //select only writeable elements
			{
				ReadOnly(ThisElement, 2)
			}
		}
		UnSetThisElement() // don’t forget to unset ‘ThisElement’
	}
}
Else // if the date is valid we Must make the elements not RO
{
	Visibility(ClosedNotice, 0)
	vLoop = 0
	While vLoop < vCnt
	{
		vLoop = vLoop + 1
		vName = @AccessStringArray(vElements, vLoop)
		SetThisElement(vName)
		vNN = @ElementType(ThisElement)
		If (vNN > 999 and vNN < 1009)
		{
			ReadOnly(ThisElement, 0) //Make them all writeable
		}
	}
	UnSetThisElement()
} 

I place this programming on the On-Form-Entry section. Any fields that should not become Read-Only should be placed in the vExemptFields string array.

Yes, the form that I use the above code on also has a subform on it, and I had to duplicate the programming on the subform's ON-FORM-ENTRY. Instead of a pop-up message (which I found made it difficult to swiftly move through the records) I just used the programming to control the visibility of a static text element. For me, it's just bright red text that says "CLOSED" - like 'closing the books' at the end of the accounting year. Maybe you could make your static text an entire sentence: "The record cannot be changed for Legal Integrity Issue"

I'm going to look into your code to prevent the changing of the system date. You must have some devious users!

I put this code in on form entry and it works flawlessly. (tweaked it just a bit)

Thanks Gentlemen!

Quote:


Good Idea. I will implement something on this line. Thanks. Still I think on exit when record is modified, warning message with @msgbox ( ) is not a bad idea.

Bharat_Naik wrote on Apr 7^th, 2011 at 9:07pm:


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.

Bharat, I put together a very simple application and emailed it to you. It seems to work pretty well.