Larry Leeth
New Member
I have a situation where the only apparent solution is based on querying the _lock table. Yet _lock is only indexed on _lock._lock-id, so I end up doing a full table scan.
The situation is that when a record is being updated, a user can invoke a 'field help' function to obtain details on the field in question, using the "frame-file" and "frame-field" functions among other tools. This functionality would exist in an include file, is part of every menu-level program.
An extension of this functionality would be the ability to find and display any audit trail records that had been created on the record currently being updated.
While "frame-file" can return the name of the table, there appears to be no means to get a 'handle' for the current buffer. However, it is possible to examine the _lock table to find any _lock table entries that reference the named table, and the current user.
WIth the name of the table, and the 'recid' of the record being updated
it is possible to then retrieve any related audit trail records.
This seems to work generally, as long as there is a fully locked record when "field-help" is invoked. If a record is merely being selected for a buffer, then the _lock table entry seems to have a value of "-1" for _lock._lock-table.
Any information on the meaning of this scanario?
Also, I suspect that in some cases that the same user could have several records locked for the same table at the same time. (by having multiple sessions actity for example). In this case, I suppose that an appropriate message could be displayed.
All-in-all, still not a very complete solution.
Any suggestions on a better and more releable way to utilize the _lock table, or other totally different solutions to the problem?
-Larry
The situation is that when a record is being updated, a user can invoke a 'field help' function to obtain details on the field in question, using the "frame-file" and "frame-field" functions among other tools. This functionality would exist in an include file, is part of every menu-level program.
An extension of this functionality would be the ability to find and display any audit trail records that had been created on the record currently being updated.
While "frame-file" can return the name of the table, there appears to be no means to get a 'handle' for the current buffer. However, it is possible to examine the _lock table to find any _lock table entries that reference the named table, and the current user.
Code:
Just some pseudocode snippets to get the idea across
/*use frame-file to get the table number*/
find first _file where _file._file-name = frame-file.
/*use the table number to find lock table entries */
if available _file then do:
for each _lock no-lock
where _lock._lock-type = "REC":
if _lock._lock-table = _file._file-number and
_lock._lock-name = userid("qaddb") then
message "File num: " _file._file-number
"File name: " _file._file-name
"Lock table: " _lock._lock-table
"Lock user: " _lock._lock-usr
"User: " _lock._lock-name
"Recid: " _lock._lock-recid
"LockID: " _lock._lock-ID.
/* else message "Not found". */
end.
end.WIth the name of the table, and the 'recid' of the record being updated
it is possible to then retrieve any related audit trail records.
This seems to work generally, as long as there is a fully locked record when "field-help" is invoked. If a record is merely being selected for a buffer, then the _lock table entry seems to have a value of "-1" for _lock._lock-table.
Any information on the meaning of this scanario?
Also, I suspect that in some cases that the same user could have several records locked for the same table at the same time. (by having multiple sessions actity for example). In this case, I suppose that an appropriate message could be displayed.
All-in-all, still not a very complete solution.
Any suggestions on a better and more releable way to utilize the _lock table, or other totally different solutions to the problem?
-Larry