I ordinarily only distinguish between one user and more than one. However the technique that I use can be generalized. Basically, you want the network to handle the problem. Because if you have it as stored data than a crash will leave you with an incorrect user count. So what you do for one user vs. many is low-level open a dummy file. You can open it read-only or read-write.

So:
1. Create a subdirectory of your data subdirectory.
2. In mainline logic, add a program that checks for the existance of the file DUMMY.001. It checks to see if DUMMY.001 is open by attempting to open it exclusively with FOpen(). If it does not exist it is created. A dummy byte or two is written to it and it is closed. We try to open DUMMY.001 and leave it open for the duration of the program. If DUMMY.001 is already open we do all this with DUMMY.002. We can do this until DUMMY.XXX Where XXX = the maximum permissable number of users.

This may sound psychotically ugly, but the information will remain correct as long as the server successfully tracks what files are open. And shutting down the server should fix any weird problems...

Adam


>Something makes me think that this is a brainless question, but believe me, I really can't find a good solution for it. This should be a common problem, right ? For example, I could wish to limit the maximum number of concurrent accesses to 3 or 5 users on a peer-to-peer install, or to a greater number on a C/S install with SQL Server. But what should I do ?
>
>I was thinking about a table of 'licensed' users with UserIds and Passwords, and a boolean field to check whether the user was already connected or not, but I admit that this doesn't seem too good. For example, if a connected machine crashes without closing the app, no changes would be reflected on the 'connected users' table...
>
>What's the usual way to deal with this kind of issue ??