....ahead with the current database, and hope the whole thing holds together, go to another tool like xCase, break it out into separate databases and write a bunch of convoluted, home-brewed RI code to handle cascading deletes, or something else I haven’t even thought of? Any suggestions from someone who has “been there” would be appreciated.

Hi Ray

I cannot really say 'I have been there' since I never used persistent relationships myself, but I had to deal with (dying) apps done by someone else who used this concept, and that was real nightmare.

It seem to me that you are in 4 lott of reengineering.
Since database is that complex (250 tables with PR/RI ) maybe you should consider upsizing it into some sort of client server solution using alternative back end like MS-SQL or Oracle.
In case of properly designed DBC with all RI in place DBC can be upsized by VFP wizard into MS-SQL database. Then real work will begin to 'finetune' all that and provide sound client-server app.
Timely & Costly - but challenging.

If application nature/purpose does not prove above aproach, then I would personnaly split mentioned database into carefuly redesigned group of collaborating VFP databases and provide RI via separate data component.

Well designed class(es) writen in separate PRG file and based on datasession object could payback investment very well. See 'Session' object introduced in VFP6-SP3.

Then you have to adjust your app (forms) to use this 'tier' instead of
'800 pound Gorilla' (LOL - Good one!)

This is just mine 2c
Good Luck :)