>>>>>>Thank you. So you do this in record validation?
>>>>>
>>>>>Yes
>>>>>
>>>>>(1) You have find out which fields may have changed ( getfldState)
>>>>>
>>>>>(2) Then for each field that may have changed - test whether it has actually changed
>>>>>
>>>>>>I know there was a reason to do this in the CA's. I hate those VFP database container stuff.
>>>>>
>>>>>I have made my own relational integrity - done a lot with triggers
>>>>
>>>>Yeah, I know it is possible
>>>>
>>>>My POV on DBC.
>>>>-All prg stuff, I like classes and inheritence.
>>>>-Any change of stored procedures are tricky in production
>>>>-and will bloat the DBC's memo file
>>>>
>>>>I have some very basic index creating stuff on it, if I have to go low level on the DBC. Anything else is in the program. (IOW integrity is on my own if I'm low level)
>>>
>>>
>>>OK, my take on it
>>>
>>>Any and all referential integrity is in the database, and not in the program, because
>>>
>>>- sooner or later you will find a program error, an update/insert, a browse, ... that violates the referential integrity
>>>- in a multi user environment, putting referential integrity in the program will fail
>>>
>>>Talked to a guy who said that all his referential integrity was in program. I answered : you scare me
>>
>>a browse? On user side? no NO NOOOOO All wrapped. They never see that level.
>>
>>17 years w/o problem.
>
>
>
>>It means nothing what will fail. The app or the code in the DBC. How do you maintain code in the DBC? Just curios.
>
>
>The database has a version code
>
>Each upgrade from version x to x + 1 is in a function ( eg create table, .... alter table, ...)
>
>Opening the database checks the version
>If an upgrade is needed, it reopens the database in exclusive mode, runs one or more routines to upgrade to the current version, the reopens in shared mode
>
>I store the dbc, dcx , dct in a table internal to the application, after upgrade I overwrite the dbc, dcx , dct

I replace the fields only from an internal copy of the DBC (in exclusive mode)