So here are some tests you can run.
1. FLOCK test 1: computer 1 (c1) opens a DBF, FLOCKs it, computer 2 (c2) tries to open the same DBF and fails with error 1705
Code
Code:
CD mappedonedrive
Use table.dbf Shared
Messagebox(FLOCK())
expected result: .T.
Code:
CD mappedonedrive
USE table.dbf
expected result: Error message of Error 1705 "File access denied"
2. FLOCK test 2: c1 and c2 open the same DBF. c1 then FLOCK()s first with success, c2 FLOCKS() without success
Code:
CD mappedonedrive
Use table.dbf Shared
Then switch to c2 and do
Code:
CD mappedonedrive
Use table.dbf Shared
Switch back to c1 and do
Code:
Set Reprocess To 1
Messagebox(FLOCK())
Expected result: .T.
Switch back to c2 and do
Code:
Set Reprocess To 1
Messagebox(FLOCK())
Expected result: .F., since c1 has the flock.
And yes, aside from Set Reprocess this is the same test code, just in the second test first both c1 and c2 open the same DBF shared and then, after both c1 an c2 have the DBF open c1 locks with FLOCK(). Notice FLOCK needs no SET MULTILOCKS ON, nor buffering of the workarea.
RLOCK() is actually quite the same, you best use it without any parameters. Its parameterization also is about a workarea in the first place, not about recnos. With no parameters, you lock the current record of the current workarea. Called with one parameter this parameter is interpreted as workareanumber, not recno. You can also lock multiple records with one call, then you need to pass in a list of record numbers, but as one parameeter, a string of the recnos. So you do RLOCK("1,2","Aliasname"). Indeed the second parameter then is the alias name, not the first. But the second parameter can't be left out for locking in the current workarea, then the "1,2" string is interpreted as alias name and you get the error "Alias not found". In very short: RLOCK() is a very quirky implementation. At best you just GO to the same recno on both c1 and c2 and then RLOCK().
3. RLOCK test:
Code:
CD mappedonedrive
Set Multilocks On
Use table.dbf Shared
Messagebox(RLOCK())
expected result: .T.
Code:
CD mappedonedrive
Set Multilocks On
Use table.dbf Shared
Set Reproces To 1
Messagebox(RLOCK())
expected result: .F., as c1 already has that lock.
Notice, both c1 and c2 are on record number 1 after they USE the DBF. You could ensure that with a GO 1 before the MessageBox(RLOCK())
From that, you will know enough. Because in the assumption c1 and c2 both use a local copy of the drive file both c1 and c2 succeed in locking. That was already disproved with your EXCLUSIVE use test, but now you also check that the RLOCK mechanism works, which is also used behind the scenes by many commands and functions and SQL. We then know that not only opening a file in exclusive mode is effective for other computers, but also VFPs quite unusual method of locking single records within a DBF.
You can of course do many more tests. One thing you can try in the last test after the c2 MESSAGEBOX(RLOCK()) returns .F. is browsing the DBF and trying to make a change in any field of record 1. That should cause error 109 "record is in use by another user" and the browse window cells remain unchanged.
And, of course, aside from Scott, anybody with two clients connecting to the same OneDrive as mapped drive can try this to check out this mechanism works. If it does, then it's clear that the computers work on the same cloud file. Nothing but VFP knows how to determine the record lock status and it's insane to assume that this locking information is coming over to other computers by synching of the files alone. So that will sufficiently prove that MS managed the mapping of network drives to OneDrive in a way that has the same quality as mapping a LAN share. I can imagine they create a VPN tunnel as the backbone of this working flawlessly but the details would only matter if you would try to implement a similar cloud share with your own means. I think the simple solution to that is WAN and the hardware and software setup to do that. It's just not as simple and end-user friendly as mapping a OneDrive is.
Ostrowlow,
I think exactly that is making it so desirable, no matter if the latency of data access is worse that way than with other solutions. By the way, you get this wrong, when you say it's about testing editing at the same time. It's about testing whether you actually use the same file. Imagine each computer has a local copy of the file and this is uploaded after a change. Imagine user 1 edits record 1 and user 2 record 2, you would expect both changes to be there, as they don't clash with each other, even with rlocks. The point is that simple synching will first overwrite the server file with one version, then the other. And in the end either the change of record 1 remains or the change in record 2, not both. This would mean only one user at a time can work on this without such bad side effects. It's unfortunately not showing up conflicts or errors if 2 users do work with DBFs in such a scenario. You'll only sometimes later not find your data or your changes. The important thing is not even that RLOCKS are working, you can work on DBFs without RLOCKS with few users, what this test proves on top of proving that RLOCKs work is that you actually have the cloud file in your workarea and not just a local copy of the cloud file that's synched with the OneDrive so frequently that it seems to you it's instant, for small files, at least.
Chriss
