I'm curious John, where, then would you implement the RI code if you don't do it the database?

The reason I ask, is because that just so happens to be the exact job of the back-end: To handle the metadata (the data that tells it what records are related to others, etc.). Implementing that anywhere else would be foolish IMO.

>Referential Integrity (RI) to maintain persistant relationships is a nice feature, but I have found that it can be slower than mollasses when maintaining relationships between large tables. My advice would be to experiment with each relationship carefully to see if you want to use RI.
>
>>Does anyone foresee (or have words of warning) about adding persistent
>relationships to an application's database?
>>
>>My app is already up and running fine: each form or report establishes own data environment. The DBC contains no stored procedures or reference definitions. (That's just the way the app got designed.)
>>
>>Now, my users have discovered the complexity of deleting parent records tied to children using meaningless primary keys and not taking the children with them. Worse, not being able to recreate the parent and have the children suddenly reappear again.
>>
>>So, someone suggested establishing persistent reltionships in the database and letting code(?) and native VFP handle the referential integrity. (Hmmm ... I've not done this before but I think I can figure it out ...)
>>
>>Words of wisdom for weary code warrior humbly requested ...
>>
>>Thanks in advance.