>If I use this strategy and I use tables instead of views what happens if two or more users try to make changes to the same table at the same time? If each workstation has it's own APP running, is the user only making changes to the data on their own workstation, and does this result in 30 different sets of data none of which are the same? I understand if I write changes to the program to put those in the UPDATES directory, but how do changes users make get written to the database on the server? --lincoln

It does not matter if users are running the app on workstations or from server. What does matter is that everyone is using the same data. So, the data is located in EXACTLY 1 place -- on the server. This is where experience, trial-and-error testing, and good coding come into play. You have to develop your app to handle multi-use/access of your data. This can be done using row and/or table buffering, the RLOCK(), FLOCK() functions, etc. How all this is applied depends on the requirements of overall data integrity. Sometimes table buffering is appropriate, others row-buffering is sufficient. Sometimes, buffering can not be used and you have to rely on RLOCK() and FLOCK() only.

The way I learned in the FoxBase+ days (circa 1989? someone please tell me it ws not that long ago!), was to put the app on 2 workstations, run both at the same time, access the same record in the same table at the same time and see what happens. Write more code, try again to see if my locking and error trapping routines were handling the data properly. Life is much easier and better in VFP because of table and row buffering.

You may want to post a new question requesting advice on good books for learning more about multi-user programming. I do not know of anything to recommend, or I would. But I would bet someone here could suggest a good starting point.