So what you are saying (I think) is that you have a DBC with tables and relationships living on the server. You also have a DBC for each client desktop. Clients open data tables on the server and create views and etc. So if you have 25 users running your program, you have 25 (50?) file handles open on the server-resident DBC.

With some recent apps, I have been able to remove table corruption by not letting any user open any tables. Users have their own DBC, but when they want data from the server, they request it and the .exe on the server gives it to them; there is only one user with open files on the server, and that is the exe.

At first, I made SQL queries and updates to the server by creating a complete text file of what was wanted in VFP syntax. Then I named the file with the username+workstationame+sys(2015)+yymmddhhmmss and copied it to a directory on the server where users only had add/read permissions. On the server side, a EXE watched the directory for new files, FileToStr() (before that it was FRead), did macro substitution, saved the result (free) table to another directory. While this was happening the client kept attempting to read in a loop from the "pickup" directory until the result was there, then it copied it locally and used it. It sounds slow, but in actuality we're talking like 1-2 seconds for the whole thing to happen. VFP is fast. :)

Since I figured out the basics of the DART webserver and service tool, I now create an EXE that runs as a service and accepts HTTP POST of an XML request. The VFP EXE does its work with the semi-final result of a cursor and then finally CursorToXML() it back as a response. Now we're still talking 2 seconds for the whole thing but it's much more flexible and easy to deploy and admin. The end result is that there is no shared table access by anyone, my app runs like SQL Server where there is a mediator taking/giving data. Actually there are now multiple "users" (STA VFP DLLs) doing data, but I haven't been able to get more than 5 going at a time because VFP always returns the data too fast to get more than 5 spawned at a time. But every data process is "local" and no matter what a client does, they can't affect what happens server-side.

Maybe the first example I threw up there can be adapted to what you are doing now.









>> I think I'm missing something. Are you saying that no users touch the DBC on the server?
>
>Steve,
>
>The users touch the DBC on the server because they are using tables that are part of the DBC. However, there isn't any code in the DBC on the server for triggers, functions, etc.