Hi larry,
>>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.

>This is only a problem if they go to another machine and attempt to login. If they attempt to login on the same machine, the logic would be to check for the existence of a login record first (everything except datetime macthes). If found, overwrite the current login record with the new login information and no count takes place.

O.K., After a bit of searching on MSDN I drew the conclusion that the logon actually is done already by SQL server and that some statisticts about the connection is available trough the sysprocesses system table. Though, the client has to have rights to read into the master database, it may be a good solution as this table also tracks crashed clients and provide more info about the clients logged on.

>I recommend using an SP on all backend platforms. You can't do this type of processing with remote views because it is too instense so you're left with SPT. Since you have to develop the individual SQL statements for any platform you use anyway (e.g. SQL Server, Oracle, etc.), why not put them in an SP. It centralizes the login code. The only thing on the VFP front-end is the call to the SP with the appropriate parameters. The SP returns a value based on success. If at some point, you wanted to change the logic of the login process, you wouldn't have to distribute a new application. You would only have to distribute a new SQL script file to update the SP.

I think you're right that it probably makes more sense to write seperate login procedures for each backend. I'll have to figure out what the best strategy is (whether or not to use the sysprocesses system table), but at least I now have some stuff to work from.

Walter,