>George,
>
>But, if I understand correctly (most of the time not) this works fine if the user is trying to run the application from the same machine, but it is still possible to run the application more than once from different machines.
>

Yes; Events are scoped to the local system; if I needed to scope a larger environment, I'd look at message queues with MSMQ, named pipes, mailslots, or any of a number of other RPC-capable synchronization mechanisms. named Pipes or mailslots probably could be adapted to the role fairly easily.

>Is there any solution other than having a locked shared file across the network?

All the methods I mention above are not built around a shared file.

>Can that solution be used with different flavors of Foxpro (VFP, FPD, FPW)?
>

Named pipes, yes for VFP & FPW, but FPW will be painful, since you'll be using FOXTOOLS to access the Win16 API calls; I'm not sure about whether mailslots are supported beyond the Win32 platform. MSMQ is Win32 only without writing wrappers on COM for FPW. FPDOS doesn't easily interface with any of the Windows APIs, you'd need to build specialized drivers to offer DOS access to Windows functions, which would require writing non-trivial code in C or a similar language. If you want to pursue this, pick up a copy of Walter Oney's Systems Programming for Windows 95 from Microsoft Press.

>I am asking not to be controversial (is that the word?) but because we are using it in real life, we ran several unatteded programs (in all that foxpro versions) and I am wondering if there is a better way to avoid running them more than once in different machines.

Locked files will work cross-platform; I'd try to stick with low-level files for this so that things like CLOSE DATABASE don't accidentally release the lock at an inopportune moment. There's also the issue of which datasession 'owns' the lock file mechanism...synchronization and messaging are two of the strongest arguments to move off at least FPDOS so that you can use Windows' services effectively.