SEQLOCK problem, when people crash, other users cant log in

hi, I was wondering if any partners out their experience this regulalrly.....

We have several sites that use Opera 3, some with say 15 users, some with 35.

In SEQLOCK, there will be on a 15 users site 15 blank fields, ready for the 15 users to log in. Once one person logs in, they take up a slot. Say theres 10 peopls logged in & one person has a crahs on say row 2 of SEQLOCK..no further users can log in

the solution, which is impractical is to get everyone out, then clear any open files in computer management, then clear anything in SEQLOCK. This works 90% of the time, but sometimes you cant clear SEQLOCK & the only solution is a server reboot.

Obviously this isnt practical on either getting all users out, or ultimately a server reboot.

We had one instance yesterday when the user was taking up slot 2 & even though we cleared that users "open files" in computer management, we still couldn't release his lock on SEQLOCK.

So the only solution was to do the first part of the above, get everyone out & clear all open files - which worked, but this one was a 30 user site.

I was just wondering if anyone else gets this & if anyone has found a more practical solution to it?

Many thanks

James

Find more posts tagged with

Pegasus - Partner General Discussions

Accepted answers

All comments

alan-bourke

We've had a large site who used to get spates of this due to Opera crashing but OPERA.EXE being left running on the PC, viewable in Task Manager. I have never seen a situation where some process *somewhere* did not still have a lock on a blank SEQLOCK record, causing the issue you describe. What happens is when user A logs in, Opera goes down each record in SEQLOCK until it finds one with a blank LK_USERID field. When it finds one, it tries to do a row lock on it. But if user B has crashed a situation can arise where LK_USERID is blanked but there is still a row lock present. So User A's login will just fail, it won't try to find another SEQLOCK 'slot'.

To list open files I use this Powershell script on the server (at an administrator Powershell prompt):

get-smbopenfile -Verbose | Where-Object { $_.Path -like '*seqlock.dbf' } | Sort-Object -Property ClientUserName

That will list the domain logins of any user or process with SEQLOCK.DBF open.

You could also have a look at OpenFilesView

https://www.nirsoft.net/utils/opened_files_view.html

To answer your other question the only real solution is for people not to be crashing!

unknown

Cheers Alan, much aprpeciated - we will have a look at your link.

We ensure the user didnt have any files left open on his machine relating to opera

then on the server couldnt see various users with SEQLOCK open in comp management, but not for this user.

Then when we went into the blank slot that he had been taking up, it wouldnt let us edit it or anyhting, coming up with the "attempting to unlock" message in the bottom left of VFP

Many thanks

James

alan-bourke

James what I would do there is get the list of users with SEQLOCK open using that Powershell command, then compare with the list of users in Opera Monitor Users. Whichever one is present in the first list and not in the second is the culprit.

unknown

Weve done that with standard windows computer management before, reaslied there was a mismatch, but even when you manually close the files, it still doesnt allow the others in. youve to get everyone out, as someone may have also had a crash that is happily working away, but still having some "ghost" open files

unknown

I have come across this many times, usually happens when Opera is aborted abnormally, like you mentioned it locks the record in SEQLOCK,

Easiest way I have found is comparing the logins (windows server manager) that have Opera files open against the user list in SEQLOCK, anyone not showing on SEQLOCK is the culprit, ending there session via Windows server manager resolves the issue or getting the offending user to reboot their PC, users need to be educated to report issues if they crash out or if they do then reboot just their PC to clear files / locks on the server.

unknown

cheers Sandip, we didnt ask the local user to reboot the PC - just checked for any opera files. But we will try this - many thanks. The problem is its quite often TS users, so we kill the opera.exe in the list of processes, but cant restart the TS as the other users are in. Then clear any open files & "sometimes" we can clear their instance in SEQLOCK, but not always

unknown

If its TS then via TS Manager you can clear the users session, rebooting their PC will have NO affect as this is the users TS session that is holding on to the files, resetting their TS session or selecting logout will clear their files / lock off the Opera server.

colin-avey

To echo many of the comments already made.

If it is 0930 we ask them to check no-one has left the Opera login form open.

TS users not login out of Opera or TS properly.

Getting anyone who has crashed out of Opera to restart the machine, not just shutdown. The server clears a lot of stuff when it sees the machine reconnect.

last resort, get the rest of the Opera users to restart their machines.

unknown

If they are using TS to run Opera remotely, then rebooting the PC will not help, since in most cases they will create a new TS sessions leaving the old one they way it was,. TS Manager or Remote Desktop Manager to clear the duff session(s) and that should do the trick.

Copyright © 2025 Infor. All rights reserved.