Skip to main content

When doing REST calls with MVIS, I understand how the u2version field works, get it when you read, and then send it back on updates so that MVIS can know if the record has been updated since you read it, implementing optimistic locking.  Wondering if there is a function that can be called from U2/PICK Basic to generate this same value manually.  We are working on some custom PICK code to read/write data in response to MVIS calls.  We'd like to use the same concept with the u2version field but calculated via PICK code on a certain item in PICK/U2.  We'd like to be able to generate this field manually for reads and then verify it on updates.  Should only add a couple lines of code to our existing routines if there is a way to easily do this from PICK. 

Looks like maybe the CHECKSUM function would do this, just wondering if this would generate the same value as MVIS u2Version.

EDIT: After doing some experiments with CHECKSUM looks like we might be able to do the same functionality to determine if a record has changed since last updating it?  The result is shorter than u2Version, about 5-6 digits, but if the CHECKSUM value still represents the state of the record, then looks like it should work ok for this purpose.  We'll send back the computed checksum when doing the read, and then sending back the same checksum value on any writes.  on the pick side, we can compare the current checksum of the record in question.  If the checksums match, then nothing has changed since the initial read, and the update can happen.  If they are different, then something changed, and the update would throw an error and not be allowed.  If this isn't the case, please advise.

Thanks in advance,

John Anderson

When doing REST calls with MVIS, I understand how the u2version field works, get it when you read, and then send it back on updates so that MVIS can know if the record has been updated since you read it, implementing optimistic locking.  Wondering if there is a function that can be called from U2/PICK Basic to generate this same value manually.  We are working on some custom PICK code to read/write data in response to MVIS calls.  We'd like to use the same concept with the u2version field but calculated via PICK code on a certain item in PICK/U2.  We'd like to be able to generate this field manually for reads and then verify it on updates.  Should only add a couple lines of code to our existing routines if there is a way to easily do this from PICK. 

Looks like maybe the CHECKSUM function would do this, just wondering if this would generate the same value as MVIS u2Version.

EDIT: After doing some experiments with CHECKSUM looks like we might be able to do the same functionality to determine if a record has changed since last updating it?  The result is shorter than u2Version, about 5-6 digits, but if the CHECKSUM value still represents the state of the record, then looks like it should work ok for this purpose.  We'll send back the computed checksum when doing the read, and then sending back the same checksum value on any writes.  on the pick side, we can compare the current checksum of the record in question.  If the checksums match, then nothing has changed since the initial read, and the update can happen.  If they are different, then something changed, and the update would throw an error and not be allowed.  If this isn't the case, please advise.

Thanks in advance,

John Anderson

I'd speculate the u2version value probably uses a hash algorithm like SHA-256 (+ Base64). This would have a lower "collision" rate than a simple CRC checksum, although slightly slower to generate.

If you haven't already, it would be a good practice to concatenate the @id with the @record contents in the checksum/hash for cases where there are identical records with different keys. 

Terms & ConditionsAccessibility statement