-P correct use

[John Esak]

Scott,

Absolutely no harm will come of using a lookup with a -p lock on the record
just because you don't post anything to that record.

If you're piece of code is solely "getting" values from a looked up record,
then there is no need for a -p on the lookup. If there is one, and the
processing does not hit an END statement for the processing table itself(1),
then you run the risk of keeping that record locked for too long a period of
time. What if someone gets to that point in the code, the lookup -p is
performed... and at that moment the user goes to the bathroom for 20
minutes? No one else would be allowed to accessed the -p locked record.

John

[1] By an "END to the processing table itself"... I mean the actual real END
of the processing for that entire record. In other words if you were to do a
lookup to a record with a -p on it from within an @wlf routine, just to say
populate an address from some customer code, hitting the END of that @wlf
routine will *NOT* remove the lock which you have put on that record. The
END encountered by the actual "table processing" program pointer is the only
one that unlocks -p locked lookups. The processing pointer for each @wlf is
separate and *unconnected* to the table processing pointer, i.e., the INPUT
TABLE or more generally the -z table for clerk.

Since there are no triggers in OUTPUT processing that can be programmed
*within* the confines of a single record as in clerk, your main worry is
clerk and its various field-based triggers.

There are some caveats, in that in both clerk and report we have some other
triggers which are neither field-based, nor table-based... i.e., @once. The
END for an @once process *will* unlock a record which was locked with -p.
The same is true for @entsel, its END *will* unlock a -p. However, these are
special cases and leave you either at @menu or at a record in @entsel's
case, so they have to make sure there are no locks working. My guess is this
is so because even though the lock may be on a lookup record... you have no
further chance of unlocking it with your code.  I suppose if you locked a
record in @once, you could unlock it again in @menu, but filePro simply
takes care of this for you and cleans up most everything after the END of
@once.  In the case of @entsel, well, you're at the END of all processing
period for that record, so I'm guessing that's why it treats the @once END
like a full processing table END, and releases all -p lookup locks.





> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.com]On
> Behalf Of Scott Walker
> Sent: Friday, June 22, 2007 5:34 PM
> To: 'Dennis Malen'
> Cc: Filepro_List
> Subject: RE: -P correct use
>
>
>
> -----Original Message-----
> From: filepro-list-bounces+scottw1=alltel.net at lists.celestial.com
> [mailto:filepro-list-bounces+scottw1=alltel.net at lists.celestial.com] On
> Behalf Of Dennis Malen
> Sent: Friday, June 22, 2007 4:57 PM
> To: filepro-list at lists.celestial.com
> Subject: -P correct use
>
> If I execute a lookup to a file and do not post to that file and a -P is
>
> used, will that corrupt anything.
>
> After the recent clarification, we understand that if we post we must
> have
> a -P. and should not have a -P if we are not posting.
>
> What happens if we have a -P and we are not posting. I have some old
> processing that still has the -P. Is it imperative that the -P be
> removed.
>
> Thanks!
>
> Dennis Malen
> 516.479.5912
>
>
>
> Dennis,
>
> You're asking what happens.  ONLY YOU CAN ANSWER THAT QUESTION because
> it entire depends on your code and what it does.  Say you do a lookup to
> a customer in the customer file just to get their Name and Address.  If
> you have used -p on that lookup you have locked the record even though
> you are not changing any of the data in the customer file record
> (posting as you say).  Does that hurt anything?   Depends.  If some
> other user is posting customer payments which include a payment for the
> customer who's record is locked, and that posting tries to update the
> balance field in that customer's record, it can't because the record is
> locked.  The user posting will get a message such as "Waiting on
> cust_master record # 2343 to be unlocked.  They will sit there for as
> long as the record remains locked by the lookup the  1st user did with
> the unnecessary lock.  How long is that?  Depends on your code and if
> the 1st user has gone to lunch.
>
> As a good coding practice, records should be locked ONLY when absolutely
> necessary and for as short a period as possible.  This minimizes
> problems.  How many problems and how big depend on your code.
>
> Regards,
>
>
> Scott
>
> Scott Walker
> RAM Systems Corp.
> ScottWalker at RAMSystemsCorp.com
> Ph: (704) 896-6549
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list