Most of my applications place everything into a single DBC, to allow for reporting across projects. In my latest apps, it seems it would be easier for the user to have a seperate 'file' for each project they work on. No cross-project reporting is needed, and it would be easier for the user to back up and delete individual projects - as well as being a little easier for the user to conceptialize.

It will involve several tables within one dbc. It would make sense for the user to use a simple FILE/OPEN kind of procedure to select a project, and FILE/NEW to create one.

There are several issues I'm concerned about for the user. One is easy archiving and deletion of projects. Another is a simple directory structure, as well as a simple an obvious UI. I presume I would want a different directory for each 'project', and keep the file names within each directory consistant - but if I do this, I'll want the user to select the directory itself, rather than navigating to the directory and THEN down to the DBC within! On the other hand, if the user deletes the contents of a directory but leaves the directory, it may be more confusing for the user!

For ME, of course, I'd like an easy way of cloning the structure of a DBC to a new and empty one. Also - should project specific info (project name, address, and similar stuff) go into another table with only one record, or into a MEM file?

I'd like to know how the pros do it - what's your advice?

TIA