Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Any way to use/save VFP 9 database/tables to OneDrive or other cloud solution 2

Status
Not open for further replies.

ostrowlaw

Technical User
Dec 4, 2009
18
US
I know I'm probably a bit late to this party, but I'm not a programmer, just a user. I run a small law office with just a few users. I started out using dBase II back on a Kaypro II CPM machine in the early ages of dinosaurs (1980s), and I've developed my office database programs over the years, first to dBase III, then Foxpro, now its running on VFP 9. Its a fairly simple program, but it runs my small law office just fine, its stable, tracks my cases, does my billing, etc. When I need to make a change, I just change it and its keeps on ticking. . .

I'm getting up there in years and I would like to spend some time in warmer climates in the winters, but I plan to keep working. Last winter I tried using RemotePC to log into my server and run that way, basically, I get a snapshot of my office computer, but its clunky and disconnects. So, I was thinking, is there some way to host my databases, indexes, etc. in the cloud like on OneDrive or something, map the cloud drive as a virtual drive (currently I do my backups using Carbonite, but I know that's not a solution). If so, can multiple users access the databases simultaneously, will the databases lock as they do now, yes a million questions.

Thanks, just need some direction to get this project going before next winter.
 
Scott,

your local test is how I also tested this, and locally you only need two instances. In fact you could also try this with only one client of a OneDrive with two IDE sessions, too. But then the scenario the local clients use a placeholder copy of the cloud file still would work locally, so to be sure you need to test with two clients.

The question is how exclusive use was propagating to the other client. It's something you would not see if you have the local file situation. But it might be the bit of information about the file handling that is shared with other clients, that the file is opened by one client in exclusive read/write mode. RLOCKs are more intricate and based on how NTFS works, by the way. It was explained in more detail in the fox wiki, that's still not available.



Chriss
 
Scott said:
...it was very fast on my PC, and the table was not small, but not huge either)

Well, when you map a cloud drive, and usually not to a drive letter but to a local folder, then the files are synched from cloud to you immediately, not just in time when you first open them. So your openinng of a dbf is always fast as long as the mapping existed for long enough to have that file synched locally.

The mapping to a new drive letter does not specify a local folder as other cloud servicees ask you, but MS mapping could just automatically set aside some local folder for that. What the actual drive letter mapping then is, is just a mapping to that local folder, and the situation is quite the same as with other cloud drives.

Chriss
 
Chris,
The dual IDE instances was what I meant by the second test. That failed the same way accessing it from 2 different PCs in 2 different locations did.

Yeah, I'm curious what OS is really sitting behind OneDrive, because it seems that is where the "magic" would reside (i.e. does it respect how an RLOCK() would work). Five years ago, the ability to map as a local drive, and have Exclusive file ownership wasn't possible. Maybe in the next few years, this will advance further. It makes since when you think about it though... why does it need to transfer the entire file in both directions? No different to how this would have worked on a Novell File Server, or a Token Ring network, etc. (or a DOS machine, or a WinNT back in the day). The thing I always loved about Fox overall was how little overhead you needed to just get a tiny bit of data and populate a screen over insanely slow LANs.
The internet is exponentially faster than my LAN connection in 1994...


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
I think a simple test that will show whether the clients can work together on a DBF would be this script:

Code:
Local lnEvenNumber
lnEvenNumber = 0
Do While .T.
   lnEvenNumber = lnEvenNumber + 2
   insert into some.dbf values (lnEvenNumber)
EndDo
Which should run in parallel to this variation for the other computer:
Code:
Local lnOddNumber
lnOddNumber = -1
Do While .T.
   lnOddNumber = lnOddNumber + 2
   insert into some.dbf values (lnOddNumber)
EndDo
And, of course, this needs a DBF with a numeric field, you can create beforehand once with CREATE TABLE some.dbf (iNum int). It will have a natural end when the dbf reaches 2GB or you interrupt this with ESC, of course.

Ideally, you find all numbers in the DBF after this runs for some time on both c1 and c2. Not necessarily in order, but without a gap.

I could understand if in the end you either have only some even or some odd numbers in the DBF. If this works on the principle that one last file sync "wins". Since syncing isn't a one-way operation, so a changed cloud file also is synched to other clients, in some cases the change of c1 could come over to c2 or vice versa. So data could also end up with mixed even and odd numbers, but if numbers are missing you'd know you don't work on this DBF in the normal shared file access, so gaps in the numbers of the final DBF will point out that OneDrive isn't appropriate for multi-user applications. And if you pay no regard to this as you say users will never insert data that fast anyway, you miss the point.

Indeed how fast you can synch a change in a small DBF to the cloud and then propagate that to other clients is the reason that simple testing by just manually writing some records on one client after the other will make you believe this works out fine. But in the end, I go back to what Rajesh told about a valid usage. It's not what you want, but it's a working use case. If you don't use a synced folder for actively working in it but a copy of that not synced with the cloud, you work simply on local data, that's working, of course. And then you can share that state of all data via the cloud drive, which propagates to other clients. They must only start working, after the new state of all data has fully synced to them, so one user at a time with a break to assure syncing is possible and the cloud drive then helps to get data to every client. A cleaner solution than, that that also works in parallel shared mode is using something as simple as a MySQL database instead of DBFs. And sure, that means your code needs a rewrite.

Coworking on Word documents or other single files is simpler on OneDrive, as each of them only allows one user and the detection of exclusive usage of a file works somehow, that's ensured. This is often done as a test case of whether the sharing of files work, but it's not good enough to ensure working on shared DBFs works, too.

Chriss
 
Yeah. The issue is well and truly dead for now.
Need to find a cloud solution that will allow drive letter mapping, and behave as a file server and not just a storage server.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
Scott,

okay, so we should officially answer ostrowlaw this doesn't work out as expected.

I'd still like to know what would result from that inserting of odd and even numbers to get a little more insight.

Here's a hint on how the OneDrive app actually syncs by describing how it was done differently in Windows 8 with so-called placeholder files and what went wrong with that design:
So I assume in the Windows 8 version MS only synced what was actually accessed. And then MS changed to syncing/mirroring. The article describes how you can get to placeholders, but that doesn't solve the problem. The mapped drive then just doesn't sync by default and you don't occupy the drive space to store your cloud files locally, too, but it would still not allow cloud access to the DBFs.

It is fair to believe the OneDrive mapping wasn't just a local mirror mapping. I still think it is somewhat different. Because if there would just be a local folder mirroring the drive, the mapped drive would actually just map a local folder as a share to a drive letter and be nothing fancy at all. Something you could also do without using the specific onedrive URL Because once you configure this local mirror folder the OneDrive desktop app syncs with the cloud, you can make that folder on your local drive a share and then map that share to a drive letter.

I was on the brink of believing MS managed to make a real mapping, it's not unthinkable as OneDrive is their service. OneDrive was MS developed from scratch, even though the name change from SkyDrive suggests it was just another of the many acquired products. The rebranding was just due to BSkyB's trademark. OneDrive always was an MS developed poduct.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top