Phil,

>My application (FPW2.6) is set up with 22 tables, each in a subdirectory of the application directory on our file server. This way, I can assign "write" access to selected individuals for different tables, and for the rest, the "ADD/EDIT/SAVE/CANCEL/DELETE" buttons are disabled if table is readonly.

The DBC is only a container of extra database information which was not available in FPW 2.6. All tables (*.dbf) are stored in separeted files in the very same way like the FPW 2.6 tables. So nothing changes here.

>How does the use of a DBC affect this approach? Let me say from the start that I really do not want to add passwords and logins to the application if I can avoid it (we spend half our lives logging in LOL).

You can also get the users name by using the winapi (Getusername as think) to determine who's is working in the app.

>I like the features offered by the DBC...long field names, min values, etc. But can I still store the individual tables that are contained by the DBC in individual subdirectories? And if so, is the DBC stored in the app directory? Do users need to have anything but readonly access to the DBC?

Users do have to have at least READONLY rigths to the dbc to get access to the individual tables.