Sync files between RDP and Local Computer

What are you using. Windows remote desktop? Connecting via an rdp file? That controls what remote desktop connection uses to connect. If you have control about the properties of the connection you can specify shared resources, so for example share a local drive and make it accessible to the remote desktop or vice versa let the remote computer share a drive with you, the client connecting.

Such shared drives will then show up in the network section of Windows Explorer within the remote desktop window (if you shrared your drive) or on the Windows Explorer on your computer (if the remote server shares a drive with you).

If you don't have control over the connection ask an administrative user to get the necessary permissions. Some RDP files even totally suppress the connection dialog and directly put you on the remote desktop, so you don't even see options. And everything differs, if you use Citrix or any other technology or even connect to something else but a windows terminal server.

Bye, Olaf.

I use Windows Remote Desktop (terminal server) and I use a programming language called Visual FoxPro - so i need an automation to sync FoxPro data files from local to RDP. The purpose is if there is no connectivity to terminal server, the user works locally. Once connection is re-established, the files from local need to be synced with those on terminal server and vice versa.

OK, that's on top of a shared drive. You run your code and it accesses the shared resource, eg reads in new files or stores new files, which then can be taken to some local only drive for "complete" transfer. Obviously, a shared resource only exists during the remote desktop connection, but it just is as if there is a local drive.

Bye, Olaf.

In the first, open up Windows Explorer on the remote desktop and in the "address line" type in the network share \\tsclient. That's the main node showing all resources the client (your computer) shares with the remote desktop. Initially you might see nothing listed, that's what you can extend with connection options. The easiest way is adding whole drives via options somwehere "hidden" in the  options you have, when you expand them before making the remote desktop connection/login.

Bye, Olaf.

I need this to be done programatically because we have lots of clients who will be using this system - so copying as needed won't work because it's going to have to be done constantly and for hundreds of people. So i need something more advanced. I don't think FTP's are the way either. I'm sure there is some way this can be done automatically using code.

Now this confuses me, because if you want consistency between all users working on same data long term, you don't exchange files at all, you make use of them all connecting to the terminal server, having a session there and addressing data and files local there, everything can stay in the refinement of the remote desktop. That's why you connect there and don't have individual per client software installations and local databases.

File transfer/exchange would only be used for transferring final result files, eg a PDF generated by a report. Nothing that is worked on later again. If the remote desktop terminal server can write that to a \\tsclient drive, it would already be transferred and exist there as local file, also after the connection is closed.

Bye, Olaf.

No, users will not be using the same data. The database structure is the same, however data is different. Example - invoices. Same table structure to store information but the data is specific to each client. so they have their own data  folder.

So the task is defined as:

1) User is working remotely via RDS but when the connection fails he must continue off-line on local PC with automatic syncing after the connection restore. Data are always in use by one user exclusively.

or

2) User is working remotely via RDS and he can switch to local PC when he decides to do so. Your code must solve the automatic or manual data synchronization between TS and local PC. Data are always in use by one user exclusively.

1) Is not easily achievable in FoxPro.
2) Is also not so easy except the case user invokes the manual data synchronization. The manual synchronization means a copy of the whole data between TS and local PC with possible lock placing to avoid parallel work on two sets of data.

Could you please tell which of the above scenarios is close to your needs?

Possible solution:
I wouldn't let users to work on TS data but just on the local PC and a special application may copy all updates from the local PC to TS when the connection is established. This copying can run on the background and simultaneously with user work. You may decide whether to copy the whole DBF and FPT files or just updated records. The copy (which can be invoked each 1/5/10 minutes) should use local PC as the first target and then another application mat copy the data to TS. This minimally affects your local app but the copying app which copies the data to TS must be ready for connection dropouts.

Data on TS should be used in r/o mode (for reporting or as backup) only.

The way of data copying between local PC and TS is then irrelevant In this topology. You may even stay with FTP.

I don't know why you still mainly think about DBFs, Pavel. The original question only talks about file transfer in general, and the other question about encryption of PDF hints rather on PDF than DBFs.

Even now we know every client has their own data folder, this can be on the desktop machine or within the network it's part of. If you go for local data and RDP, I wonder what for the RDP connection would be. You share a whole application including its data in a remote desktop, not just the application and surely not just the data.

Bye, Olaf.

Let me publish the citation from Shamina:

I use a programming language called Visual FoxPro - so i need an automation to sync FoxPro data files from local to RDP.

Also the question is in FoxPro zone so why to talk about file transfer in general?

Data syncing between local and RDS is obvious question when the internet connection is unreliable or not available. I have clients running apps locally and synchronizing data via e-mail transfers... with all the disadvantages.

The syncing requirement is reasonable if people cannot stop working just because the internet is down.

Found it. But where did I talk of Oracle?
I already explained with cross reference to another post of Shamina Maharaj, why I talk of PDF. Unimportant now.

But let me take your word for granted, why would you offer a software as a service in a remote desktop you serve, when data should be individual to every customer local? If you want each user to run on his individual data, then sell a software installing on the client pc or clients company network. I don't get how you would use the remote desktop concept in such a situation at all. It doesn't make sense to have local data as fallback, in that case you can simply work "offline" all time, there's no need for a remote desktop setup at all.

Bye, Olaf.

Oracle was just an attempt for a joke :-).

Shamina's concerns about the RDS availability were actual in our country years ago. We don't have such problems now when even wireless connection (5GHz WiFi or LTE on mobiles) is fast and reliable enough.

OK, I didn't get that.

But you hit the nail with availability. A Remote Desktop becomes unavailable when internet connectivity is broken, It won't help to have local data if you don't have the application clientside too, to act on the local data. And the concept of an offline fallback would need a clientside software installation you normally want to avoid using remote desktop. The remote desktop window doesn't work like a browser, it's even less than a browser just a viewer of the remote desktop. So there's nothing that would continue to work offline.

Bye, Olaf.

Yes, and for that reason I am proposing to work fully locally with something like on-line backup in the background.

Pure VFP application (without unnecessary OCX add-ons) can be just copied from the server and that's acceptable for the everyday's work and automatic app updates.

Thank you so much guys... the reason i cannot allow a user to work on local is because when we upgrade our apps, its more easily managed on TS instead of local. So all clients get the new features. RDP will be the main working environment and only in the case of connectivity issues will users be allowed to work locally. Data needs to always be up to date to avoid duplications of invoice numbers, etc.

To have the TS as the main storage/station with (current!) data copy on each local PC is not easily achievable. There will still be a delay in the synchronization and the possibility of duplicate invoice numbers creation.

Application running exclusively on local PC does not have such problem. It can check for new versions on each start and update itself when necessary. It will also work faster than via RDS. Everything depends on your RDS availability and reliability. The advantage of on-line backup (which needs some programming effort) will surely bring an added value.

Of course, the added value of FoxPro is questionable today but if you have a lot of work done then the app update is still the cheapest way of any enhancement implementation.

BTW, If I would have time then I would do something like distributed database in VFP - Local work and automatic syncing between several locations at the background. The only question is whether this approach is worth to implement today in VFP... So the app still retrieves updated data and sends e-mails and updates from other sites on button click...

If Shamina has no additional questions then I would propose to split points between Olaf and me.

I have decided to use Web Services to accomplish this. So my Web Service continuously synchronizes data between local databases and RDP databases. Thanks for assisting experts :)