Hi Bill Where is the update program. If it is a UniData subroutine, then UniObjects is not in the process. As far as I know UniObjects has no locking process of its own, it uses Unidatas lock table. I have not experienced this problem, this issue like this sounds like a program bug.
I would step through the logic carefully, as you may be locking the record twice in 2 different processes as part of the update. Is DB doing an update through its application at the same time you are doing an update. Check the subroutines call logic. Check the security access, does the user have write access. I suspect a process is aborting somewhere that leaves a record locked which is only cleared when the UniObject session is cleared. Have you done a "list.readu all" after a record locked message has occurred, as you might identify the lock has occurred then. PS did you do LIST.READU or LIST.READU ALL Regards David Jordan -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, 9 January 2012 6:34 AM To: U2 Users List Subject: Re: [U2] Uniobjects and Record Locking David: Thanks for the input. This has nothing to do with DB, as the message that displays is generated by the update program due to the LOCKED clause being taken, even though there is no record locked. We do a quasi-optimistic locking and only lock records during those few milliseconds where updating occurs. A record is "NEVER" locked until an update occurs, and since locks release when a program terminates (even a subroutine returns) we shouldn't be having such problems ( i.e. a record is never locked then left alone). This is why I'm thinking it has something to do with Uniobjects. Thanks again, Bill ------------------------------------------------------------------------ ----- Original Message ----- *From:* da...@dacono.com.au *To:* U2 Users List <email@example.com> *Date:* 1/8/2012 1:33 AM *Subject:* Re: [U2] Uniobjects and Record Locking > It is possible that design base is running a separate locking mechanism that > it is caching. The Uniobjects connection involves pooling where multiple > user accesses use one UniVerse Login. This is different to a telnet > connection with one user per login. If DesignBase cannot identify the > process that updates as being the same as the one that locks the record then > you could have a problem. You cannot identify who locked the record in a > pooling environment as 10 people would have the same user ID, hence it has to > be managed by designbase rather than universe. > > What you are doing is pessimistic locking. With a web based environment and > pooling, you should be thinking optimistic locking where you only do locking > at the time of update and compare before and after images. If a user locks > a record over an internet connection and then loses a connection, then that > record can remain locked until an administrator releases it manually, this is > why pessimistic locking is avoided in this environment. > > Regards > David Jordan > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill > Haskett > Sent: Sunday, 8 January 2012 10:16 AM > To: U2 Mail List > Cc: DesignBais Support > Subject: [U2] Uniobjects and Record Locking > > I'm using DesignBais and have run into an unusual problem. When I display > some data on a web form the dbms is contacted through UO and the returned > data is displayed. When I click on the [Save] button the same UO connection > is used to contact the dbms and run whatever program is required to update > the record. > > In the called update program, the record is read and locked. If it's already > locked the program terminates and a message is returned informing the user > the record is locked (try again). If it's not locked the record is updated > and, of course, the program terminates in the same manner. > > Problem: if I edit the record via UniData's AE editor (LIST.READU shows a > record lock) and try to update the record via the DesignBais form, the LOCKED > clause is taken. This is good. However, after I release the record via the > AE editor (LIST.READU now shows nothing locked), then click on the [Save] > button, the LOCKED clause is still taken, even though no record is locked! > If I kill the UO connection, DesignBais will make another UO connection and > all works fine. > > So, it appears a UO connection won't release a lock under whatever > circumstances I've happened to stumble upon. Any ideas what causes this and > how to "work-around" the problem? > > Thanks, > > Bill Haskett > Advantos Systems, Inc. > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users