Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Good practice of tracking table changes
Message
 
 
À
27/12/2008 15:11:08
Dragan Nedeljkovich
Now officially retired
Zrenjanin, Serbia
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Versions des environnements
Visual FoxPro:
VFP 9 SP1
Divers
Thread ID:
01369848
Message ID:
01369862
Vues:
10
>>Hi,
>>
>>Once in a while when I look at my competitors databases (not necessarily VPF) I see that almost every table has a column of DateTime type indicating when the record was last time changed. My tables don't have such a column. Is it a good practice to have a DateTime column in every table to store when the record was last changed?
>
>If you intend to synchronize your data between two locations, it's a must. With proper timestamping (with identity and/or location of the operator) you can develop a nice cross-updating scheme. I had one in '97, worked just fine (except that they used modems and/or floppies to ship data, and that part never worked), another one in 2004 (to update remote SQL from local DBFs).
>
>The way it worked for me was to know the time of the last successfully sent package; next time, send only those records which were updated after that time. On target, you can have a conflict if someone else (person B) updated the record with a timestamp higher than the arriving one (made by person A). You can resolve it either way - by overwriting, ignoring, or comparing fields in the audit trail and writing changes made by person A only for fields which person B didn't update... or anywhere between these. It can get as complicated as you want :).

Dragan,

Thank you for your input.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform