>>Another thread about a dbc not being able to find its tables brought this question up for me - having not yet rolled out many apps in varied situations.
>>
>>If one stores all dbc(s) and tables (and .exe, etc) in a single directory on development drive of e:, will problems develop if app is eventually installed in directory of same name on drive c: ?
>>
>>What about directory of different name?
>>
>>And I should ask the same questions about how a dataenviroment would act in a changed drive:directory location.
>>
>>I've been assuming that references to tables were relative from apps location rather than explicit from drive letter on down.
>
>When the .dbc and its tables are in the same directory information is stored in relative paths. I've never split my data structure across directories, or drives.
>
>I generally have a directory structure that has the project name as its root, and locate the .pjx there. Beneath that are directories for forms, reports, programs etc.
>
>In the other case, where data is distributed in different drives and directories, moving it is more difficult. Doug Hennig (I think) had an article when VFP first came out about moving a database structured in such a way. The complexity fixedfor me: .dbc, .dbf's and indexes all on the same drive.
>
>Regards - Miles Thompson
>
>P.S. I'm patching an old FPW 2.6 app, written by another consultant, where all references to screens, reports and tables are hardcoded with both drive and directory structure. Each time I think I've found them all, WAP, I get slapped across the face by another. GRRR!

WHOOPS - stand corrected. Andy Neil did the article, not Doug. I believe he wrote a Mover program at the same time.