>>As a double newbie, you've got enough to worry about. If there's no compelling reason not to, put everything in one directory on the server. Your app will never have to think about where the files are, and only one copy of the app will have to be updated.
>>
>
>I disagree here; the issues of finding the data and fixing up database refs during the process of opening the tables are virtually identical whether everything is in a single directory or several. Unless the application and DBC are developed and deployed in the same place, or the DBC is created programmatically at the site, either using a tool like SDT or code that came from something like GENDBC, the database references have to be fixed up. Learning to store a path in the registry or a local configuration file and read it at runtime are just not that tough to do, and not be locked into a single location buys you a lot:
>
>(1) The application can move to a different location and the mechanism for handling the new location already exists in the code.
>(2) You can deploy more than one data set by having each dataset in a separate folder.
>(3) The performance hits from a directory with too many file entries are minimized.
>(4) The operating system requirements to have multiple security requirements for different files are reuced - for example, you can deploy on a file system with folder-level granularity rather than file level granularity and not be forced to grant the maximum set of file access requirements on all files.

Basically, it should be 2 mechanisms here, one to store/change data files/folder locations, and another one to 'adjust' database references in run-time.