If I use some incorrect terminology, please excuse me. I don't know all of the ins and outs of Pervasive, but I have programmed with it for years.

I ran into this problem a few years ago and now I am experiencing it again in a different application. When I lock a record in a client form, and then I try to lock it again in the same client form to see if the initial lock still existed, it will show it is unlocked even if it is locked. I have tested it by reading the locked record with a different client form and it is defiantly locked.

 Is there a setting to resolve this and is there a reason the behavior exists?

 
-Justin

Your post piqued my interest so I decided to attempt to reproduce your problem here with the Btrieve interface. 

I am using Pervasive.SQL v10.01 Client connecting to a Pervasive v10.01 server and the Pervasive Function Exector to make Btrieve calls directly. 

1. Launch two copies of wbexec32.exe
2. In each copy, use the file-->open command to open up sample.btr located in the pervasive samples directory
3. In copy #1, enter op code 212 -- this is get first record, with single lock.  Enter datalen of 4096 to allocate enough buffer space for the record.   When you click execute you will see the data load into the display.
   
4. In copy #2, repeat the steps above.  When I click execute in this copy i get "Btrieve status 84 - the record or page is locked".  This is the behavior I would expect to see.
   

If you try these steps with your local client, do you get the status 84 at step 4 like I do? 

Thanks

Ron
 

 

Lock requests issued from the same client using the same clientID will behave as you described.  The engine assumes that if you are the same client instance, you already own the lock and it's not going to generate a conflict.  In the Function Executor example, even though both instances are running on the same workstation, they get different clientID instances, so the engine knows they are separate "user sessions". 

 In a single application, if you want to look like distinct users, you need to re-open the file with a different clientID and attempt to read with a lock using that clientID.  Then, you will get the status 84 if the lock is still active.

Wow, thank you for the response, that is exactly what I am experiencing! I will probably just make another workaround.

 

Thanks again!