ProDataSets and record ID

Posted by David Ysmael on 12-Dec-2017 08:55

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

Posted by ChUIMonster on 12-Dec-2017 11:28

I strongly advise you NOT to pursue programming that uses _LOCK.  Yes, it is better in 11.4+.  But it is still not exactly lightning fast and there are plenty of pitfalls to be found.  And if anyone running something older than 11.4 runs your code it will not be pretty.

I think you would be better off lobbying for the LOCKED-BY() imaginary 4gl function.

The 4gl clearly knows which user has the record locked and is able to immediately provide this information in that delightful error message that such and such a record is locked by so and so on device such and such.  99.44% of all temptations to use _LOCK would vanish if LOCKED-BY() were an actual 4gl function.

All Replies

Posted by Mike Fechner on 12-Dec-2017 09:01

By record ID, you refer to a RECID ? If you insist on a RECID, you'll have to populate that yourself to a temp-table column in the AFTER-ROW-FILL call back.

If you want to go to a ROWID, create an additional temp-table field of type ROWID and attach that to ROWID(dbtablename).

But all that is bad practice. From the backend you should not expose such an internal detail to the outside world. Use a PUK that's meaningful to the client as well instead.

Posted by Peter Judge on 12-Dec-2017 09:02

Did you take a look at the DATA-SOURCE-ROWID ?
 

Posted by David Ysmael on 12-Dec-2017 10:27

I should have included this in the OP, but reason I am trying to retrieve the record ID is to pull 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. I did see the after-row-fill call back option and was considering that. This is being implemented in a RESTful service, so the recID will not be exposed externally, it's only being used to reference the row in the lock VST.

Posted by James Palmer on 12-Dec-2017 11:21

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?

Posted by ChUIMonster on 12-Dec-2017 11:28

I strongly advise you NOT to pursue programming that uses _LOCK.  Yes, it is better in 11.4+.  But it is still not exactly lightning fast and there are plenty of pitfalls to be found.  And if anyone running something older than 11.4 runs your code it will not be pretty.

I think you would be better off lobbying for the LOCKED-BY() imaginary 4gl function.

The 4gl clearly knows which user has the record locked and is able to immediately provide this information in that delightful error message that such and such a record is locked by so and so on device such and such.  99.44% of all temptations to use _LOCK would vanish if LOCKED-BY() were an actual 4gl function.

Posted by James Palmer on 12-Dec-2017 11:37

Ah yes I remember now, something to do with the new _userlock table in 11.6.

Posted by cverbiest on 27-Dec-2017 03:51

Late addition to the discussion

It should be possible to find who locked a record with the LockConflict

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvref%2Fprogress.lang.lockconflict-class.html

and https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/gspub/handling-stop-conditions-using-stop-objects.html

*Progress.Lang.LockConflict — The AVM throws an instance of this class when a time-out occurs while waiting for a record lock or when the user presses Cancel in the dialog box displayed during the record lock waiting period. This class also provides public Device, TableName, and User properties to identify the device, database table, and user that holds the record lock.

run 2 simultaneous sessions with  -lkwtmo 10 -catchStop 1 executing the code below

block-level on error undo, throw.

do transaction:
    find first customer exclusive-lock .
    name = name + ".".
    validate customer.
    pause.
    catch se as Progress.Lang.LockConflict:
         message "Lock conflict"
         se:Device se:User se:TableName
         view-as alert-box.
    end catch.
    catch e as Progress.Lang.Error:
         message e:getmessage(1) skip
         view-as alert-box.
    end catch.
end.
message "done".

This thread is closed