Hi Mike.

While putting DBCs on a local drive is fine for DBCs that contain only views, I'm not a fan of that technique for DBCs with tables. The reason is that if the DBC and tables are on separate drives, VFP uses absolute paths in the DBC (the path to the table) and DBF header (backlink to the DBC). That means all users have to have the same drive mapping.

>1. How do I place the DBC locally and still have the data on the server?

For a new DBC, simply create the tables on the server; VFP will store the paths in the DBC and DBF header. For an existing DBC, you'll need to use one of the utilities that comes with SDT to change the paths in the DBC and DBF headers. I'm at home right now and don't have access to the SDT docs, but it's described in the SDT help file.

>2. How does this affect Stonefield updates?

It doesn't. SDT properly handles the paths to the tables.

>3. and How do I develop locally, and then deploy the finished product on a server? i.e. dbc local, data on server.

You have to develop using the same pathing structure e.g. DBC on C: and tables on J:.

>Therefore where would the Stonefield files go?

It doesn't matter where they go; when you instantiate DBCXMgr, you specify the path to the SDT files.

>If local, how do I get them to all of the workstations on load?

You can copy the files from the server to the workstation as part of the app startup.

Having said all this, I recommend you spend some time looking at the performance issues rather than assuming having the DBC locally will help.

Doug