Problem with RLOCK() 2

[Steve-vfp9user]

Hello

I have set up a home network to test a multi user app I am trying to deveop. I have a problem with RLOCK()

The following code has been placed in a prg to access a table:

USE mytable1 SHARED
GO mpurchrec  && Where mpurchrec is the RECNO()
SET REPROCESS TO 3
IF RLOCK()=.F.
  =MESSAGEBOX("The Order you are trying to access is being updated by another user"+SPACE(10), ;
    0+64+0,"System Message")
  RETURN
ENDI

No problem with the above code which works perfectly.

I have the same code in another prg the same as above but to update a record in a different table as below:

USE mytable2 SHARED
GO mjobrec  && Where mjobrec is the RECNO()
SET REPROCESS TO 3
IF RLOCK()=.F.
  =MESSAGEBOX("The Job you are trying to access is being updated by another user"+SPACE(10), ;
    0+64+0,"System Message")
  RETURN
ENDI

This doesn't work and allows the same record to be opened by two users on different computers at the same time.

I also tried removing the =.F. after the RLOCK() command but this just locks the record straight away.

There are multiple threads on this forum relating to RLOCK() and the VFP help file doesn't give too much away. I can't find the answer to my question so any assistance or guidance would be much appreciated.

Using: Windows 10 / Visual FoxPro 9 with SP2

Thank you

Steve

 

[Mike Lewis]

With SET REPROCESS in force, the behaviour of the lock depends in part on whether you are using a function or a command to update the record. It also depends in part on whether or not an error routine is in force.

I suggest you read the paragraph under the heading [tt]Parameters TO nAttempts [SECONDS][/tt] in the Help topic for [tt]SET REPROCESS[/tt]. (But be warned: it's not easy reading.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

First, removing =.F. makes you check the opposite, so that can't possibly work.

The code is similar and in itself okay, are you sure you have a) the same mjobrec number and b) at time of RLOCK have selected the correct workarea? Check out the value of DBF() at time of RLOCK()

Your code works for me changed to lock a record in the sample data in two VFP IDE sessions in Windows 10. This eliminates any network effect, as it's a local file, but I don't assume doing so with a network shared DBF would cause a problem.

m.rec = 6

USE (_SAMPLES)+'\NORTHWIND\CUSTOMERS.DBF' SHARED
GO m.rec 
SET REPROCESS TO 3
IF RLOCK()=.F.
  =MESSAGEBOX("The Customer you are trying to access is being updated by another user"+SPACE(10), ;
    0+64+0,"System Message")
ENDIF

Do you have the problem initially or after a few LOCK/UNLOCK iterations only? And what's your SET MULTILOCKS setting and CURSORGETPROP("Buffering")?

Bye, Olaf.

 

[Steve-vfp9user]

Hello

There are no problems initially as when I try to open a record that I know is open on another computer, I receive the correct message as described above.

It's only when I try to open another table that it doesn't recognise that he record is already open and that I should have the message the record is being updated etc.

SET MULTILOCKS is OFF as the help file suggests: "(Default) Allows you to attempt locking a single record with LOCK( ) or RLOCK( )"

I have to admit I'm not sure what CURSORGETPROP("Buffering") means as I've never used it and I am fairly new to this multi user app creation.

I just wondered if the RLOCK() and RLOCK( ) made any difference but I've tried that and it doesn't

I appreciate the quick responses from you both.

Thank you

Steve

 

[Mike Lewis]

I have to admit I'm not sure what CURSORGETPROP("Buffering") means as I've never used it

I doubt if that's relevant in this stage. Given that you are explilcitly opening the tables, there has been no opportunity for you to set the buffer mode, so it would be at its default settings, which is "none". So the issue won't arise.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve-vfp9user]

Thanks Mike

I'm completely baffled by this because why should it work for one table and not the other?

I'll keep digging so to speak....

Thank you

Steve

 

[Olaf Doschke]

Well,

for tables in a form DE the form DE settings will take precedence and then you may set buffering or other cursor properties for workarea 0 and thus make it the default for any new workarea you use.
It would most probably be at default for someone not even knowing about it, but you never know what happens if someone uses a framework having much code never looked at, or code inherited from an earlier develoepr in the project...

Bye, Olaf.

 

[Steve-vfp9user]

Ok, I feel daft but I have to post this in case someone else is looking for the answer to the question I posted.

In my start.prg I have the following:

SET BELL OFF
SET CENTURY ON
SET CLOCK OFF
SET CONSOLE ON
SET CURSOR ON
SET DATE BRIT
SET DEBUG OFF
SET DELETED OFF
SET ECHO OFF
SET ESCAPE ON
SET EXCLUSIVE OFF
SET MULTILOCKS ON
SET SAFETY OFF
SET STATUS BAR OFF
SET STATUS OFF
SET SYSMENU OFF
SET TALK OFF

For some reason SET EXCLUSIVE was set to ON not OFF

Even though commands such as USE MYTABLE1 SHARED were issued, it didn't make any difference and in particular where I had linked tables on a form and tried to access the linked table, when I tried update a record I had a message: File access denied.

By simply changing the ON to OFF that appears to have resolved my issue so I'll keep trying to break it so to speak to make sure all the permissions are where they should be.

If nothing else, thank you Mike and Olaf for your time.

Thank you

Steve

 

[Mike Lewis]

Glad we were of some help, Steve.

I was surprised to read that the table was opened exclusively even though you specified SHARED in your USE statement. I thought that SHARED would override SET EXCLUSIVE ON. At least, that's what the Help says:

SHARED allows you to open a table for shared use even when EXCLUSIVE is set ON.

However, I just did a quick test, and it looks like you are right that the table is still opened exclusively, even with USE ... SHARED. So either I have misunderstood what is happening or the Help is incorrect.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Hmmm. I'm having second thoughts about SHARED not overriding SET EXCLUSIVE ON.

This was my first test:

* Open a new instance of VFP.
* From the command window, type:
SET EXCLUSIVE ON
USE Sometable SHARED

* Open another instance:
SET EXCLUSIVE OFF
USE Sometable SHARED
* No good. "File access denied"

So on that basis it looks like the file was opened exclusively in the first instance.

But here is my second test:

* Open a new instance, and type in the command window:
SET EXCLUSIVE ON
USE Sometable SHARED
MODIFY STRUCTURE

The Structure dialogue is showing Read Only, which indicates that the table is opened for shared use after all (as I would have originally expected).

I must be doing something stupid. (Probably the Friday afternoon syndrome.)

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Ah, I think I can see what's happening.

The problem occurs when the table belongs to a database. When you issue the USE command, it automatically opens the database for exclusive access (assuming it's not already open). That's because EXCLUSIVE is ON at that point. Then it proceeds to open the table, which is open for shared access (because you have the SHARED clause in the USE).

In the other session, you repeat the process. But this time you can't open the database, because it is already open for shared access. Hence the error.

Steve, I don't know whether that applies in your case. If it does, the solution is to open the database explicitly before you open the table. You do that with OPEN DATABASE <database name> SHARED. (Or alternatively just set EXCLUSIVE to OFF at the outset and keep it that way.)

I have now repeated my tests with a free table, and it works exactly as expected. So my apologies to the author of the Help topic. It was correct after all (of course).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes Mike,

the database is one thing playing a major role, the other is the EXCLUSIVE setting per datasession, though the help says the default setting for EXCLUSIVE is ON for a VFP session and OFF for forms with private datasesions.

Anyway, the exclusive state of having the table open will guarantee any RLOCK to work, you obviously are the only one having that table open. On the other hand, that means no second user could start up the same form opening same tables without an error. I earlier asked you to look at DBF(). I think there might be yet another situation you're not taking into account: Every user having their own database locally. Shared access obviously needs shared files in one central file server share. In the moment I don't see how you get both no errors and all locks, than each user working with their own single user database.

Bye, Olaf.