I would love nothing more than to break the link between the DBC and all of its tables. Before my predecessor departed (retired), he did break some of the links to the EMPLOYEE.DBC file, because he kept having so many problems. I inherited all of this mess; he is an engineer without any FoxPro training. I've had to rewrite many of his programs; they are all strange, but do work, strangely enough. We have a 24-hour operation so it is difficult to break those links, because you have to be ready for things to be back online quickly.

In regard to the proper setup of our development environment, I think we'll pull the network cable out of the DEV PC and fix things up.

>>I did take the DBC out of the project, but then the predecesor programmer put it back in so that he could see real data. And some of the data environments open that same DBC and those files point to live data. It's a true mess. This is part of the reason I do not want to use DBC's.

>I think we faced the similar problems using MereMortals framework and trying to do some exotic tests using local copy of the application against Network copy of DBC or vice versa. As I recall, we had issues and it never worked 100% reliable for us.

>If you're sure you never would need DBC capabilities in the future, may be you can make all your tables free and see, if everything works as is?