Welcome to the SRP Forum! Please refer to the
SRP Forum FAQ post
if you have any questions regarding how the forum works.
Apparently there is a basic + command called list_keys . When i call it, i get variable unassigned though. Does this function work?
when i declare it as a subroutine instead of a function, it doesn't crash, but how do i get the list of keys?
As you may have noticed, this is documented as a
rather than as a
(or even a
). Routines don't behave the way normal functions and subroutines do and as such they normally aren't used in developer routines. Routines typically route their response to the system
ok oh well.
i guess i will have to use another cursor to select all of the keys in a table....
I am trying to select all of the keys in a table inside of an mfs, so using cursor 0 will not work as it may already be in use...
edited August 29
Look at this: POP.SELECT:
ok that is good. thanks i will try that.
btw, do you know if it's possible for me to access the local lock table on a particular workstation?
I am referring to this:
in regards to list_keys,
would this help
take a look at this upgrade
I do not know of any way to access the local lock table.
I am just going to go with the push and pop thing that don suggested, but thanks.
ok no worries. would be good to be able to see it. oh well.
what, exactly, are you looking to accomplish if you
edited August 29
I am trying to see who has a lock.
In the business I work for, an unknown person holding a lock on something can be catastrophic,and we had a nasty case of this happen last week.
At the moment, we track in an mfs whenever someone locks/unlocks a particular thing, but this method doesn't' work if the user's computer crashes (but there is a way to get around this...)
Anyway, All of this would be much simpler if I could just see the local lock table on each workstation; that's why I asked.
Anyway, the mfs thing will work 100% (after i have made some changes to it)*, so it's not a big deal that i can't look at this local lock table, it would just be nice.
*except only on tables that have been setup with the mfs, which isn't all tables (we have 100s of tables in our system). But i have a way of getting around this too lol...
The new locks list routine I showed you shows a table of locks - what file/key/who
That tool still has problems as others on the forums have pointed out. Still, I agree that it is worth trying to see if it works.
We've had to write our own utility that knows how to ask who owns the lock and then we can send a request to release the lock. This has been useful for when access to the database server is limited or when the UD Manager locks up when there are large numbers of locks.
"We've had to write our own utility that knows how to ask who owns the lock and then we can send a request to release the lock. This has been useful for when access to the database server is limited or when the UD Manager locks up when there are large numbers of locks."
How does this work? We are making something similar I think.
In the TIMER event on every workstation, we are going to put some code that checks if it should check if the workstation has a lock on a particular record. If it does, it will report back to US. This plus the MFS should cover all the cases.
We are using our
control to support peer-to-peer communication. A workstation can then send out a message asking who owns a lock and the workstation with the lock then responds right away. This same utility is also used for many other "messaging" based uses within the application, including instant messaging, shutdown warnings, forcing apps to close when unattended, etc.