Multi user n/w access and file locking (95 / 3.1)

Dear All,

I'm writing an application requiring two types of user - normal and

The user logs in and gives their password - these are stored locally in
binary files. Security is not important, just that I can differentiate
users and store information related to them only. In addition, it does
not use the BDE at all.

I originally wrote this as a standalone app which supported many users
but not simultaneously - e.g. installed on one computer which 5 people
might have (sequential) access to.

I now have to upgrade this to make it run on a network - this could be
Win 3.11 / Win 95 / NT / Netware / Lantastic / etc. That way,
 * the n/w administrator need only perform one installation, and
 * data is stored in one place and accessible by all stations... etc.

The problems are the usual ones of users attempting to update the
same files at the same time - the files are just files created by
TFileStream objects.

There should only ever be _one_ advanced user, and I have been trying
to achieve this by the following code:

>  LockFileStream := TFileStream.Create('C:\lock.txt',
>     fmOpenWrite or fmShareDenyWrite);

Then when a second master user attempts to log in, an exception is
raised because it already locked, and the second client can reject
the login attempt.

This works great running two instances of my EXE locally on my Win95
machine - the 2nd attempt to lock the file fails as expected and
the user can't therefore proceed.

There are two concerns that I have:

  1) I have not got access to a network yet and am unsure if this
     approach is any good or if it's a hack of sorts
  2) It doesn't seem to work on my other machine (Win3.1) - when the
     second client attempts to lock the file, no exception is raised
     and the user proceeds! Bummer!

Can anyone shed any light on this for me - I need to decide if this
approach is good enough to work across a network ...

  MyNetworkExperience := nil;

... and as you can see, if it is good enough I am stuck on the other
problem, and if it is not good enough, I am unsure what the
alternatives might be! Bit of a dilemma, eh?

All replies greatly appreciated!


Chris Sexton