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

For VFP "databases", any and all RI code runs solely on the client computers, so is subject to the same issues as any other program code in a multi-user file-server database environment.

As I see it the benefits of VFP database RI:

- Lets developers "enforce" RI declaratively rather than having to write their own code to do it. Handy for those who don't have the time or skills to do so

- Related to the above, provides code that is well-tested. Although I understand someone wrote an improved drop-in replacement (Steve Sawyer?) which devs should be using by default, unless they're rolling their own

- In effect enforces a single code base for RI across all machines accessing the same DBC. No worries about client program version issues etc.

It doesn't buy you any of the cool features such as multi-phase commit, transaction logging etc. unless one does that oneself. Given that there's no DB server process managing access to the various DBC files there are limits to what can be done.

ISTR years ago someone on this forum was developing a VFP database server. Around that time various true RDBMSs were being commoditized and released in free/libre Express (or full) versions. I don't think there was ever much of a use case for a VFP database server.