Here's an outline: an app is installed. It has its DBCs. Now the customer buys another app, which has its own DBCs. Some of the tables appear in both DBCs. With free tables, I've simply stored the directory where the table with (possibly) displaced table resides into a variable, and changed just the directory (it was stored in some config.dbf so it could be changed at install without touching the code). So, if the second app was a standalone, the var remained empty, otherwise it had _other_dir=FullPath("..\other_app\") and the tables were opened with openOK=Open_it(_other_dir+"customer") If the second app had its own customer table, _other_dir="". Now, how'd it work with DBCs? One solution which may seem to work without touching much of the code, would have _other_dir=FullPath("..\other_app\")+"other_dbc!" in the shared case, and _other_dir="Local_Dbc!" Still, this would work just for opening tables. How's the RI and other things? VFP, for now, appears rather single-app oriented. We've managed to build systems of several apps working together, transporting data between them etc, with the only restriction being (partially) standard structures of common tables, and configurable directories (so the apps could be set up with proper paths to the tables). As I expect to have "cram it all into one big app" as one of the possible answers, I expect it to have very low rating. Reasons - maintenance, modularity, customer related problems (sometimes they buy first two just to see, and to have their staff used to it, and to have their directors convinced it's good to buy more etc, and last but not least, not all the customers need all the components).