I'm posting this here so that others are not surprised by this *MAJOR* defect while planning on going live with SM 7.00.010 (build 010) -
We can only hope that HP gets 7.01 out the door and fixes this issue in time for a go-live date (with sufficient testing). Luckily we're not in production already!
SCR 40808 - If a user access a record through the queue screen, such as IM1001, and makes an update - the SM binaries create a probsummary;NULL (or filename;NULL depending on the module the queue is displaying). This <filename>;NULL lock does NOT get released after the update completes. After that, any user who access a DIFFERENT record (again utilizing the queue screen) and attempts to capture a lock (binaries again try to get probsummary;NULL or whatever module is being used as an example) and because the probsummary;NULL lock already exists, the message that the record is already locked get displayed.
This means that while the <filename>;NULL lock exists, no other users will be able to update records if they utilize the queue screens to access records of a specific module that has the rogue "NULL lock" present. This occurs when using either web or eclipse clients, and appears to remain an issue until the server cleans up the lock or the user terminates their session (which also cleans up the lock).
It does not appear to be a problem if accessing records through the "search" screen as opposed to the queue.
Ouch - the pain of cutting edge.


Reply With Quote



Bookmarks