-p on LOOKUPs - further clarification?

[Bruce Easton]

John Esak wrote Monday, June 18, 2007 4:27 PM:

[..]
> These -p locks are "record" sensitive and related... not file based...
[..]
>
>   1  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        . If:
>        Then: end
>   2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> @keyT  . If: '@keyT
>        Then:
>   3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        . If:
>        Then: lookup one=test r=("1") -p
>   4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        . If:
>        Then: mesgbox "no prolbem so far"
>   5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        . If:
>        Then: lookup two=test r=("1") -p
>   6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        . If:
>        Then: mesgbox "still no problem..."
>   7      If:
>        Then: end
>
>
> If you were to run this... you would see that it passes just fine.  Why?
> Because, *you* own the lock on the record, so nothing is going to prevent
> you from doing something to that record... like locking again with a
> different alias if you want to... but I can't see the programming
> reason for
> doing this.
>
> John Esak
>

Sorry - again I'm a bit off of what Jay was after, but John, your case
is interesting  - I never thought of not being lookup protected from
one's self as in your example above.  And I can't see a need for it
either.  Nevertheless, I could not help but try the following:

(myfile input table)

         If:
       Then: end
  2  -------   -   -   -   -   -   -   -   -   -   -   -
@keyS    If:
       Then:
  3  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: lookup tst = lfile  r=("1")  -np
  4  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: mesgbox "no prolbem so far"
  5  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: system "/appl/fp/rclerk myfile -s0 -z inp2"
  6  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: end
  7  -------   -   -   -   -   -   -   -   -   -   -   -
@keyC    If:
       Then:
  8  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: lookup tst = lfile  r=("1")  -np
  9  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: mesgbox "no prolbem so far"
 10  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: call "inp3"
 11  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: end
 12  -------   -   -


where myfile/prc.inp2 (via system command - @keyS) is:

  1  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: end
  2  -------   -   -   -   -   -   -   -   -   -   -   -
@menu    If:
       Then: lookup tst = lfile  r=("1") -np
  3  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: mesgbox "still no problem"
  4  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: exit


and where myfile/prc.inp3 (via called table - @keyC) is:

  1  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: lookup tst = lfile  r=("1") -np
  2  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: mesgbox "still no problem"
  3  -------   -   -   -   -   -   -   -   -   -   -   -
         If:
       Then: end


In the case of the system command, filepro issues the
waiting for record to be unlocked message for the
for the lookup at @menu.  (The called table lookup
passed fine.)  So, I guess where you say "*you* own the lock,"
"you" must refer to the current filepro process?

Bruce

Bruce Easton
STN, Inc.