Logging Changes Made

[Raheel Ahmed]

Hello all,

I have come across a situation where users of my application need to be notified of changes made by other users of that same application.

I have come up with a solution but it doesnt work to the desired effect:

Situtaion: When the supervisor logs in and makes changes to the form the values he enters in the fields will turn to red and bold color. So that when the other user (clerk) opens the same record in a form those values are differentiated with the bold red color.

Solution that did not work: I semi-accomplished this by writing code for the onchange event for each field on the form that goes like this:

-----------------

if user_groups()="Manager_Supervisors" then
this.font.color = "red"
this.font.bold = .t.
topparent.refresh_layout()
t1 = table.current()
t1.Updatedby = user_name()

end if

-----------------

Then I used the field properties of each field to construct color and font properties such that the font and color would be bold for the field if the following expression would be true: GARDENING->Updatedby""

However, my problem lies in the latter part of the method. When this method is applied to all fields on the form and any one field is changed by the supervisor, then when the clerk opens the same record in the form all fields become red and bold. I know exactly why this is happening: because even if one field is changed then a value is being entered into updatedby field for that record and the field properties of that record checks the "updatedby" field to make the judgement to bold and color the field.

HOw can I overcome this such that the application would know if the supervisor made changes to a field on the form and then make that fields font bold and red if the clerk opens to view that same record?

Please help me. Any ideas would be appreciated. Thank you

[Tom Cone Jr]

RE: Logging Changes Made

It seems to me that you'll need an "updated by" field for EACH separate field on the form. Your present approach supplies a single "updated by" field for the form as a whole. To change the color of a single field Alpha needs to know who last modified it, and it alone.

-- t

[Raheel Ahmed]

RE: Logging Changes Made

Thanks for the prompt reply Tom. I was afraid that someone would reply back with this solution. It seems so cumbersome that in order to simply figure out if a field in a table was changed the solution would be so involved.

Does V6 offer another approach that simplifies the situation? Perhaps even, a function which can be used or manipulated to figure out if the value of the field was changed by a certain group member?

I just want to avoid creating extra fields in the application which would inturn add size to the database as a whole.

Actually, I really dont care who (username) has updated the field (just the fact that he was a member of a certain group) or what the last value of the field was; therefore, I think i can avoid creating the "updated by" much less "last value" or "new value" fields for each existing field of the table.

How about this: if the field was updated by a certain group member then to the the users of the "clerks" group that fields name would appear in a Rich Text on the form? Would this work?

Hypothetical Solution: The onChange event of each field would monitor the usergroup making the change and the onDepart would add the field's name to the Rich Text on the form. The rich text would be viewable to only the members of the clerks group. Which would inturn show the name of the field that was last changed by a member of the supervisor group.

[Tom Cone Jr]

RE: Logging Changes Made

Raheel,

In light of the additional information you've furnished, I'd recommend something MUCH simpler (At least for your text fields). I'd embed a visible marker or code in the field value when it's entered or changed by a member of the supervisor group. For example, if the actual field value is "Apples", I'd add a prefix "*" automatically if the field is entered or edited by a supervisor. All users would see "*Apples". Instantly they could see both the actual field value, and know that the field value came from a supervisor.

Embedding a code like this violates database normalization rules. However, it may be a practical solution for you.

-- tom

[Tom Henkel]

RE: Logging Changes Made

I agree with Tom. The only way to determine what type of user updated a is to have a flag somewhere in the table stating WHO did the last update. How about setting up a 1 character field which is calculated. The value of this field is changed based on the person or group modifying the corresponding form field. In this way, you could set up the field properties to chech these flags and then set font color and properties based on the flag.

It would be no fun to set up, but once done, it should be pretty automatic. The logic is fairly simple,and it is the same for every field and flag.

Tom

[Raheel Ahmed]

RE: Logging Changes Made

I think that is a great solution and would suffice my needs perfectly for forms and viewing data but then this solution would give a lot of problems in the reports that I have for the tables.

First of all all fields in the table are numeric, secondly all fields are being used for calculations in reports...

For example, I make it so that it autochanges the fields value with a preceding "*" for every field that a supervisor changes but then I have a report that calculates the total's for each field and the extra "*" symbol would inevitably create errors in the calculations.

Hmmm...i dont know what else could be done, but I am surprised that although so simple this task is to the mind it is becoming so difficult to implement. I would think that it would be a fairly common practice in a database to know who was the last user who updated the fields.

[Tom Cone Jr]

RE: Logging Changes Made

""I am surprised that although so simple this task is to the mind it is becoming so difficult to implement. I would think that it would be a fairly common practice in a database to know who was the last user who updated the fields.""

Not so. In my experience a very common requirement is to log the date, time, and identity of the last person to change the RECORD. You're trying to log changes to individual FIELDS, a very different, and unusual, requirement. Your design essentially requires two tables to be maintained. One to record the values in each field, and another to record the category of user who made the last change. Your specifications double the complexity of your application.

The suggestions made thus far are simple, but tedious and time consuming, to implement. Once in place it should run automatically and transparently for the user.

If the benefits of knowing when field values were last entered by supervisors outweigh the time/cost of implementing a field by field solution, only you can your client can say.

-- tom