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