>The problem is it has grown into a monster. There are over 250 tables, and managing the whole thing in VFP’s Database Designer is a bear simply because of the physical on-screen size, number of tables, and a massive spaghetti bowl of relationship lines...

>What’s your opinion on the best way to handle this? Should I just forge ahead with the current database, and hope the whole thing holds together...

We run quite a few applications that look a bit like the one you mention HR systems with hundreds of tables, most of them linking thru a PERSON_ID ...

My own two cent is thas this application should use (or have used) a db engine as a back-end. Possibly this is difficult or even impossible at this stage of development. I expect that the application has overgrown the initial architecture and that the db complexity was not anticipated at the beginning... But, for sure, massive and complex RI in VFP may become a bit tricky (personal opinion).

You could clear the pb do a full "re-basing" of your product from dbf/dbc to a c/s architecture where RI is safe and manageable even on the most demanding scale.

DB-server such as Sybase ASA - cheap, lean and fitting midsize volumes - or MS SQL server - not for the faint of heart, costly but supporting any kind of volume. Managing (and documenting) RI for hundreds of tables in such products is a joy.

VFP 8 offers an acceptable way up for dbf-based application into c/s via cursoradapters. But it's not a one-day job:(

Franck