Resolved ProDataSets and record IDs

davidYsmael

New Member
I am trying to find a way to return the data-source's record ID of a specific record in the ProDataSet. When I use the recID() function on the record within the ProDataSet's temp-table, it returns a record ID that is specific to the ProDataSet (afaik) and not the data-source. Is there a way to retrieve the record ID of the record in the data-source from the record in the ProDataSet, or an easy way to pull the record ID as I'm filling the ProDataSet? TIA
 

TomBascom

Curmudgeon
Working with RECIDs is a slippery slope that always ends badly. You might want to take the hint and reconsider your approach.
 

davidYsmael

New Member
Tom,
Thanks for the advice. The reason I am trying to retrieve the record ID is to retrieve lock information (user name, terminal name) when save-row-changes fails because of an active record lock. Previously I found that the record ID was an easy way to find the record pertaining to the lock in the _Lock VST. Ideally, we wouldn't have any situations where a lock is placed on a record for an extended period of time, but in our Organization, we don't have that luxury. It would be nice if I could retrieve the lock-id of the lock that causes save-row-changes to fail, but I haven't found any way to do that.
 

TomBascom

Curmudgeon
You're not just on the road to hell... you're in the fast lane.

Queries against _LOCK are a bad, bad, bad idea. They sometimes seem to work reasonably in a DEV environment but they are a horrific train wreck in most PROD environments - especially in PROD environments that experience the sorts of problems that drive people to want to do this kind of thing (yes, it's a "Catch-22").

-LOCK is "better" in 11.4+ where the VST data is snapshotted -- but it is still a long ways from being something that should be embedded without a lot of forethought and testing and a simple method to disable it when it all goes awry.
 

TomBascom

Curmudgeon
FWIW -- I understand *why* you want to do this. And I think that it should be trivial -- after all the 4gl knows perfectly well who holds the record and is quite capable of telling you that in the message that you get when there is a lock conflict. We shouldn't need to use _LOCK to duplicate that -- we /should/ be able to use the i4gl function LOCKEDBY() to get that information.
 

Cringer

ProgressTalk.com Moderator
Staff member
I wasn't paying full attention at the time, but I think someone at EMEA PUG (possibly Rich Banville) said that it's possible to establish who has a record locked much more easily in 11.7.2, using the VSTs. Can anyone confirm this?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I wasn't paying full attention at the time, but I think someone at EMEA PUG (possibly Rich Banville) said that it's possible to establish who has a record locked much more easily in 11.7.2, using the VSTs. Can anyone confirm this?
He did a session last year on what's new in the VSTs in 11.7 (quite a lot!). I don't see anything in there that exactly matches this.

You could, I suppose, get the rowid of the record, turn it into a recid, and query it in _lock or _userlock, both of which have recid fields. (Caveat: I haven't tried this.) But this isn't great for several reasons.
  • It's a table scan.
  • If you're using TP or MT, you also have to get the partition ID to make it a unique query.
  • If I recall correctly, _userlock only has info about the first 512 locks, so you might have a false negative.
  • _lock can potentially change much more quickly than the ABL can query it.
  • Depending on the size of _lock, this could be a costly query.
Just curious: if the user or program does get this data, what do they plan to do with it?
 

davidYsmael

New Member
Just curious: if the user or program does get this data, what do they plan to do with it?
In my case, I'm creating a RESTful service to perform CRUD operations on the DB from the web. When a record is locked, I return an HTTP status code of 423 and in the response body I would indicate the record is locked and provide the username and terminal session where the record is locked. The user doesn't do anything with it. Currently, it helps us to figure out where the locks are happening and fix the logic that's causing the record to be locked when we're attempting an update. It's not necessary and it only assists us in patching our legacy system.

After seeing the responses to my question, I'm going to heed the advice of Tom and rethink our approach to handling locked records.
 

Cringer

ProgressTalk.com Moderator
Staff member
He did a session last year on what's new in the VSTs in 11.7 (quite a lot!). I don't see anything in there that exactly matches this.

You could, I suppose, get the rowid of the record, turn it into a recid, and query it in _lock or _userlock, both of which have recid fields. (Caveat: I haven't tried this.) But this isn't great for several reasons.
  • It's a table scan.
  • If you're using TP or MT, you also have to get the partition ID to make it a unique query.
  • If I recall correctly, _userlock only has info about the first 512 locks, so you might have a false negative.
  • _lock can potentially change much more quickly than the ABL can query it.
  • Depending on the size of _lock, this could be a costly query.
Just curious: if the user or program does get this data, what do they plan to do with it?
It was something to do with _UserLock and _Lock. Like I say I'm trying to piece together info from a distracted brain and a slightly vague Powerpoint.
I think the idea is that there's now a _Lock-TransId field on _Lock that joins to _Trans table.
And you're right _Userlock seems to be limited to the first 512 locks. So could be limiting.
Like I say I wasn't 100% paying attention at the time due to committee distractions, so I may have mis-remembered/heard something.
 
Top