Problems with a FIND statement

Find or for each will only read records that match the selection
criteria specified. HOWEVER, id you are searching on an unindexed field,
it may have to read every record to complete the tests. Thus if any
record is exclusively locked, and you are reading with share or
exclusive locks, you will be stopped by a locked record. A way around is
do the read no-lock, and then lock the record you want. For example
(Version 8 and above):

for each mytable no-lock
where my-table.some-field EQ some-condition:

repeat:
/* if the record is locked wait for it silently */
find current mytable exclusive-lock no-error no-wait.
if available mytable then leave.
end.

do-some-stuff.
end.

HTH

Luc Morin wrote:
>
> Hi all,
>
> I'm trying to update a record in the Part table. I have tried both using
> FIND and FOR EACH to do the job, but each time I get stopped by other users
> modifying a part in the Part File Maintenance, even if that part is not the
> one I'm trying to modify from my code.
>
> The problem is that I need to either put a SHARE-LOCK or EXCLUSIVE-LOCK in
> order to modify the record, but if someone is already modifying a part, a
> dialog box shows asking me if I want to wait until the other user has
> released the record.
>
> If I understand correctly, when you do a FIND or a FOR EACH in a Progress
> procedure, Progress tries to lock each record, as they are read, with the
> lock level specified (SHARE_LOCK by default). What I'd like confirmed is if
> ALL the records in the table are "read", or only those that match the WHERE
> condition. If all records are "read", how can one ever modify a record using
> a FIND or FOR EACH if someone has already an EXCLUSIVE-LOCK on one of the
> records in the table ?
>
> Could I do my FIND with NO-LOCK and then somehow lock THAT record for
> modification without having to do another FIND as suggested in the progress
> help:
>
> ----- FROM PROGRESS HELP -------
>
> By default, Progress puts a SHARE-LOCK on a record when it is read (unless
> it is using a CAN-FIND function, which defaults to NO-LOCK), and
> automatically puts an EXCLUSIVE-LOCK on a record when it is updated (unless
> the record is already EXCLUSIVE-LOCKed). A record that has been read NO-LOCK
> must be reread before it can be updated, as shown in this example
>
> DEFINE VARIABLE rid AS ROWID.
> FIND FIRST customer NO-LOCK.
> rid = ROWID(customer).
> FIND customer WHERE
> ROWID(customer) = rid EXCLUSIVE-LOCK.
>
>
> --- END PROGRESS HELP -----
>
>
> >From that code snippet, the second FIND will try to put an EXCLUSIVE-LOCK on
> each record as they are read, which will result in the same problem if a
> user has an EXCLUSIVE-LOCK on any record in that table.
>
> I'm not too sure I understand how records are locked in FIND/FOR EACH
> statements. Can anyone please confirm/infirm ? Also, can anyone offer a work
> around ?
>
> Many thanks,
>
>
> Luc Morin
> Electrical Designer
> Wulftec International
> lucm@...
> (819) 838-4232, ext. 232
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/links
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
/* ================================================================*/

Specialists in Progress Databases and Software since 1986

William E. Colls william@...
PROComputer Systems Tel 613 591 0079
67 Willow Glen Dr. Fax 613 591 3924
Kanata Ontario Canada www.procomsys.com
K2M 1T1
Hi all,

I'm trying to update a record in the Part table. I have tried both using
FIND and FOR EACH to do the job, but each time I get stopped by other users
modifying a part in the Part File Maintenance, even if that part is not the
one I'm trying to modify from my code.

The problem is that I need to either put a SHARE-LOCK or EXCLUSIVE-LOCK in
order to modify the record, but if someone is already modifying a part, a
dialog box shows asking me if I want to wait until the other user has
released the record.

If I understand correctly, when you do a FIND or a FOR EACH in a Progress
procedure, Progress tries to lock each record, as they are read, with the
lock level specified (SHARE_LOCK by default). What I'd like confirmed is if
ALL the records in the table are "read", or only those that match the WHERE
condition. If all records are "read", how can one ever modify a record using
a FIND or FOR EACH if someone has already an EXCLUSIVE-LOCK on one of the
records in the table ?

Could I do my FIND with NO-LOCK and then somehow lock THAT record for
modification without having to do another FIND as suggested in the progress
help:

----- FROM PROGRESS HELP -------

By default, Progress puts a SHARE-LOCK on a record when it is read (unless
it is using a CAN-FIND function, which defaults to NO-LOCK), and
automatically puts an EXCLUSIVE-LOCK on a record when it is updated (unless
the record is already EXCLUSIVE-LOCKed). A record that has been read NO-LOCK
must be reread before it can be updated, as shown in this example

DEFINE VARIABLE rid AS ROWID.
FIND FIRST customer NO-LOCK.
rid = ROWID(customer).
FIND customer WHERE
ROWID(customer) = rid EXCLUSIVE-LOCK.


--- END PROGRESS HELP -----


From that code snippet, the second FIND will try to put an EXCLUSIVE-LOCK on
each record as they are read, which will result in the same problem if a
user has an EXCLUSIVE-LOCK on any record in that table.

I'm not too sure I understand how records are locked in FIND/FOR EACH
statements. Can anyone please confirm/infirm ? Also, can anyone offer a work
around ?

Many thanks,


Luc Morin
Electrical Designer
Wulftec International
lucm@...
(819) 838-4232, ext. 232






[Non-text portions of this message have been removed]