The default behavior made it multi-user unfriendly. A lot of that likely came from trying to remain dBase compatible and beginner friendly. It was actually on

The default behavior made it multi-user unfriendly. A lot of that likely came from trying to remain dBase compatible and beginner friendly. It was actually one of the better (behaved and performing) multi-user DOS and early Windows databases I used that wasn't based on a client/server architecture. It was up to the developer to take care to avoid unnecessary locking. For example, you could open databases in read only mode, avoid locking when browsing via 'browse nomodify', don't lock the database until you actually needed to do your CRUD work etc. If you migrated apps to utilize SQL and other 'modern' (at the time) FoxPro features instead of the legacy FoxBase/dBase syntax much of this was taken care of for you. I had production databases with up to 100 concurrent users before the overhead of the locking mechanism really started to be a problem. (which back in the NetWare days was more than enough for many mid-sized business applications) Just by way of comparison, I saw lots of 'what the hell were they thinking?' multi-user MS Access deployments starting in the late 90's that were even worse... without the ability to mitigate the way FoxPro apps could. That said, of course client/server databases still scaled better, farther and easier.