Hi larry,

>You could use the same methodolgy and use a semaphore table to hold logged in user information.

>You could store the user name, machine ID and datetime when the user logs in. When another user attempts to login, you could run a count on the current login records to determine if they are allowed in. The following rules could be applied:

>1. If the user is already in the table under a different machine ID, you could assume they are attempting to login in twice and prevent them.

>2. If it is the same machine ID and you have code in your application to prevent multiple instances of your application, you could assume they exited the application abnormally.

I don't feel much for restricting users to log in twice. Besides this mechanism has a security hole in it: When a client is dead and does not start up anymore, the application still thinks it is active.

>You could also have a timer built into your application that updates the login record at some interval. The login process could delete all "old" information before it runs the count so no users who had exited abnormally and simply left for the day would be included in yuor count.

This is an interesting approach. I see only problems when some problem occurs where more than one users crashes and try to logon again before they're marked dead by the timer. This means that the timer should not be set to a large interval.

>All this processing could be included in a Login SP to centralize it on the server.

What is the role of a SP for this ? querying and updating the logon table can also be done with SPT or a view. It is preferred to make this application as much DBMS independed as possible.

Thanks again for this idea.

Walter,