I posted a message a couple of weeks ago regarding a problem with the NT/2000 Service, 2.1, running TCP/IP on a Win 2000 server. All workstations are all NT 4.0. OpenInsight 3.7.0. I haven't got any closer to resolving the problem at this stage.

When a machine needs to be rebooted while in OpenInsight (e.g. the machine has locked up) the user remains listed in the SYSLOGINS table. If they try to log into the application again (after rebooted the machine) they get the error message:

Cannot select on SYSLOGINS, lock held by another user.

Logging in with a different station id allows the user to log in, but the entry remains in the SYSLOGINS table, reducing the number of user who are able to get into the system. The only way to get rid of the rogue entry has been to restart the NT/2000 Service. This is quite drastic, as all of the other users have to log out of the application.

Is this a possible bug in the NT/2000 2.1 service? Is there some setting I am missing? Is there any other way to clear out the rogue entries?

Paul Rowe

Vernon Systems Ltd

Paul,

Are you running the NT/2000 Service connections using TCP/IP or are they using Named Pipes?  Have you tried using the whatever the other protocol is to see if there is any difference?

Also, is this the *exact* text of the error message and *exactly* how is this error message being reported?

Pat

Sorry about the double posting - I got trigger happy :)

The message was relayed to me over the phone by the client - I got them to read out the message again and it should be:

FS415 - cannot select on SYSLOGINS - lock is held by another user.

They are using TCP/IP. I'll get them to try using Named Pipes and see what we come up with.

Cheers,

Paul

Hi P@,

We've tried switching from TCP/IP to Named Pipes (I'm replying on Paul's behalf) but that doesn't seem to have made a difference. It does seem particular to the NT Service 2.1 - ie, these problems start happening once they've upgraded to the new service. We're getting it at a number of client sites now.

Anything else we can look at?

Cheers, M@

I don't know if this directly helps but ..

In the Create Event of our Start Form, we do the following to get

rid of bogus SYSLOGINS records (abort, etc.):

OPEN 'SYSLOGINS' to SYSLOGINS THEN

 SELECT SYSLOGINS  ;* R/BASIC SELECT

 L0:

 READNEXT ID THEN

    LOCK SYSLOGINS,ID THEN

• YOU CAN SEE WHICH RECORD HAS THE LOCK SET

• IT WILL BE LOCKED BY YOURSELF AND ANY OTHER USER WHICH

• IS REPORTED BY THE OS AS HAVING A LOCK

    END ELSE

• DELETE THE BOGUS ENTRY

       DELETE SYSLOGINS,ID ELSE

• HANDLE THE ERROR

       END

    END

    GOTO L0

  END

END ELSE

*oops the SYSLOGINS Table is missing

END

Don Miller

C3 Inc.

I must say th@ P@ and M@ thing you do is r@her ne@…

- Oystein -

Thanks Don,

But I would have thought you would have done the Delete in the THEN clause of the LOCK, not in the ELSE clause. If you are successfull in setting the lock, then OI hasn't set the lock, implying that it would be a bogus entry. If the Lock fails, then OI has already set the lock as expected.

See Don's solution.

Cheers, M@

- you should hear my answer phone message:

"Hello there, this is M@

I'm not here, in the fl@

I don't know where exactly I'm @

but tell me you rang, and I'll get back"

ha ha - M@

View this thread on the Works forum...