I'm revisiting my thread of last week with the same results: I have a master
table of idnos that my app must process. The app looks for a record that has
a processed flag set to false and rlocks() the record, if it fails to get
the rlock(), it moves on to another record and repeats this procedure until
it finds a rec it can rlock(). The purpose of this activity is to prevent a
given idno from be processed multiple times. Unfortunately, when I run
multiple instances of the app on a *single* work station, the rlock is
ignored and all instances find and process the same idno. I've verified that
multilocks in on, and that I'm not moving the record pointer. Is it possible
that the rlock() is owned by the workstation rather than the application
instances that are running on the workstation (ie once one instance has an
rlock(), all instances automatically share it)?
My old, DOS-like method of creating a low level 'flag' file with
fcreate() and testing for file handle > 0 works fine.
-Lew

Re: Rlock() & multiple instances of app by Lew

Lew
Mon Jan 15 14:14:17 CST 2007

Yes, I've got now. Thanks. I'm amused to see, however, that rlocking is much
more memory intensive than my old fcreate() flag file method.
-Lew
"Cathy Neppel" <CathyNeppel@discussions.microsoft.com> wrote in message
news:49119FD3-5FE0-4A6E-B31E-DED904DBE42C@microsoft.com...
> Lew,
> The 2 running apps won't share locks. Open 2 instances of VFP on your
> machine, point both at a table, lock a record in instance 1, instance 2
> cannot rlock() that record.
>
> Can you see it happening in the debugger?
>
> "Lew Schwartz" wrote:
>
>> I'm revisiting my thread of last week with the same results: I have a
>> master
>> table of idnos that my app must process. The app looks for a record that
>> has
>> a processed flag set to false and rlocks() the record, if it fails to get
>> the rlock(), it moves on to another record and repeats this procedure
>> until
>> it finds a rec it can rlock(). The purpose of this activity is to prevent
>> a
>> given idno from be processed multiple times. Unfortunately, when I run
>> multiple instances of the app on a *single* work station, the rlock is
>> ignored and all instances find and process the same idno. I've verified
>> that
>> multilocks in on, and that I'm not moving the record pointer. Is it
>> possible
>> that the rlock() is owned by the workstation rather than the application
>> instances that are running on the workstation (ie once one instance has
>> an
>> rlock(), all instances automatically share it)?
>> My old, DOS-like method of creating a low level 'flag' file with
>> fcreate() and testing for file handle > 0 works fine.
>> -Lew
>>
>>
>>