Re: Forms4.5 row locking

From: Sridhar Subramaniam <avion_at_ozemail.com.au>
Date: 1995/12/09
Message-ID: <30C9D75A.4C7_at_ozemail.com.au>#1/1


Steve Cosner wrote:
>
> I have a form which has a base-table block, and in the block, there
 is
> a non-base-table item. In a post-query trigger, the non-base-table
> item value is set. This causes the form to mark the row as changed,
> and locks the row in the database.
>
> This process prevents any other users from using the same form with
> the same data.
>
> Am I missing something obvious? What is the "right way" to
 accomplish
> this? Until the user actually changes an item from the base-table,
> I don't want the row locked.
>
> (We can work around it by setting up another block with the
> non-base-table items, but this requires a bit of extra work to keep
> both blocks in sync by row.)
>
> Are there some item properties on the non-base-table item to set to
> keep the form from locking the row?
>
> Please, anybody with some hints on this, could you pass them along?
>
> TIA,
> Steve Cosner

Steve,
Looks like you have enabled the "lock record" item property for the non-basetable item. The default is disabled. If you have this property on, FORMS will lock the current record on changes to the non-basetable item.
Digressing a bit, be sure your post-query is just making changes to the NBT items. If it is changing base-table items, you might have to either use set_record_property to change the record status to QUERY or change the trigger from POST-QUERY to POST-CHANGE; you will get the commit warning otherwise. POST-CHANGE comes in very handy in such situations where it is making changes to base table items, during a query, and you don't want to get the commit warning.

-- 
Cheers

Sridhar Subramaniam
Avion Consulting Services
Sydney - Australia
Email : ssubrama_at_nibucorp.ccdn.otc.com.au / avion_at_ozemail.com.au

Disclaimer : All opinions are truly and just mine.
Received on Sat Dec 09 1995 - 00:00:00 CET

Original text of this message