Hi, John.

>I get the example of zip code and city, though in this case I think the second user is the problem and you can't rely on another responsible user to be already editing every time this user tries to edit just a zip code. ;-) I've posted a few points in response in my other reply to Pertti.

Of course this is the typical dumbed-down example. I worked on several projects having many of this cross-information issues, like service trouble tickets, where many different groups can be editing the same trouble ticket at the same time, as some are checking the network, other are calling the user, while others are doing monitor-based checking, and so on. The same applies with complex workflow interactions where an activity can be made up of several potentially simultaneous tasks carried on by different people, and all of them can change properties at the activity level.

In most of these cases you have to carefully isolate information blocks and treat them as separate parts no matter how they are actually normalized in the db. There, simple and automatic field-level independent updates can be very dangerous, and the kind of rules applied are something you definitively want out of db constraints, because it constantly evolves and it is too volatile.

Of course, for many cases -the ones you typically handled, as I see- your change tracking strategy works well. Once again my point is that we have to take in consideration that what looks like "the most usual scenario" for one is not the same for other people. In the VFP community there is a more uniform type of application because the tool is very specific, but a general purpose language or platform have to go way beyond that.

I hope this doesn't sound like just generalities again... :)

Regards,