>>>Or you could maybe simplify things and copy the dbc to where the tables expect it to be. If you've moved/copied the tables, you should have done the same with dbc/dct/dcx - they usually travel together.
>>
>>The simple solution. No - that's too easy! <g> And it just won't work. The DBC is on the W: drive and the full path is stored. The data is on the J: drive and the full path is stored. My dev machine is set up completely differently and this company has a number of locations where the drive mappings will be different from all of that. I need a very flexible solution. Thanks for the reply.
>
>I've done a lot of crazy and potentially unstable things over the years, but I've never even tried to introduce this sort of separation between dbc and its dbfs. Good luck.

Well, I knew I might find something of use for this in SDT. I checked the docs and Doug's FixDBC utility should give me the guidance I need to get this done. It's a little crazy, but it lets me get to where I need to go. In the long run, I may be able to do away with this. Now, one thing I haven't checked . . . is the source code available for this utility!