Hi,
Background:
I'm planning to load db changes via a batch process.
Unfortunately I can't always guarantee no users are busy in the affected application - which will block the DB change.
Question:
Is there an easy way to find this out with ABL code?
What I have tried:
I tried _userLock tables, but I can't always find a user name / connection name - it is blank sometimes. I initially ignored blank, ? and root _UserLock-names and if I found more than 1 user I aborted my DB change process. This worked fine untill we added Fathom management - which registered a new user causing my code to abort the DB change. Obviously this approach is not correct.
I had a look at the _connect table. This seems to give a valid answer if I check the connect.connect-type = "REMC".
Are there any better and/or more foolproof ways of checking whether I can go ahead to load the DF?
Thanks,
Georg.
So long as your are in multi-user mode any check that you might make with VST based code could be invalid micro-seconds later. It only takes one user, local or remote, deciding to update something to derail your process.
You can:
1) Kick everyone out and go to single user mode (not ideal for several reasons).
2) Create some sort of "lock out" script and then disconnect everyone. (Hard to code and disruptive.)
3) Try it. If it works it works. If not retry later.
I usually use some variation on #2 -- there are various tricks to make it more reliable like changing /etc/services so that remote connections fail and/or renaming the db until you're done.
You should also make sure that product development and your sales rep know that an "administrative lockout" which lets an admin do things like this (and index rebuilds etc.) while the db is up in multi-user mode (but which prevents regular users from logging in) would be very useful. Some small steps have been taken in this direction with 10.1C but there is a lot more yet to be done. Encourage the engine crew to work harder on it!
Thanks for the response!
I hear what you say about the VST based code. It seems to be working for the moment but I'll probably migrate my solution to your suggestion (1 and 2) going forward.
Regards,
Georg.