>>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!

You'd need to write to tables' headers and into a binary field in the dbc (in the records of Table type). For the first, you need to fOpen() the dbf - just make sure that you first create a link to a dbc with a long path, so that you can replace it with a shorter one (plus a null byte trailing!) in the dbf's header. As for the binary in the memo in the dbc, I assume the same technique would work - strtran(memo, oldPath+chr(0), newpath+chr(0)), but you better export the memo into a file and look at it under a hex lens. These binary memos aren't exactly rocket science, and aren't really complicated. You just need to care about the trailing bytes, and maybe the prefixing bytes. I know I've hacked that when I was writing my indexer, and at some point I had to excise the primary key info from there and let it be put back later. Um... think that the trick was in issuing a Compile Database every two steps :).