>>>>>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