How to make a program run on remote computer

[AlastairP]

I have a application running on a Windows 2008 R2 server. Office users access the application locally on the LAN.
I have tablet users with a mobile version that has a cut down database on their tablets.
When they need to update their tablets back to the server, they connect to the server database with wifi and the tablet runs a 'sync' to update the server database.
The tablet users are technicians who are field based, and they need to be able to enter and edit data regardless of the availability of internet.

However, the cpu in the tablets is low power and therefore the sync process takes quite a while.
What I would like to do is create a program that can reside on the server do do the heavy lifting.

I need to find a way to make the program start and run on the server, not to execute locally on the tablet (which is normal behavior when executing a remote program)
Can anyone help with a way to achieve this?

 

[Tore Bleken]

http://foxincloud.com/

 

[Olaf Doschke]

In your situation you'd like to let the syncing be done from the server side instead of the tablets pushing data, the server should pull out data, right?

Well, you still will need to copy over the data somehow and that's merely limited by the wifi speed, not CPU speed. If you think you can get better, first time how long it takes to copy over the local tablet data to say a folder per tablet on the server. I think you only could reduce the time the tablet is involved in this process and users can go back to work earlier if you make it the first step to transfer the data as is without involving the target table, just plain new files or staging tables filled with the data to sync. But if you make syncing the last step of the work schedule done by the tablets in their dock for recharging overnight, it would also not matter how long the tablets are involved, as long as it doesn't take all night. I don't know if that's applicable and users need to sync more often during their office hours.

It's true whatever you start via shortcut or batch file runs on the tablet, there's no direct way to start something serverside within just file shares you see clientside. But you could run a server-side process, maybe even a service, that reacts to requests or monitors a directory or table for jobs. But before you go that route, simply first determine the time the pure copy of data takes, you can't reduce this time by using the server CPU instead of the tablet, that's an I/O bottleneck, not a CPU bottleneck. If this takes significantly less time than your current sync process then perhaps you're doing complex transformations of data or cause some cascading updates or whatever else, then it could be helpful that's done serverside with the data copied over in the form of simple DBF or CSV files as the first stage. The overall process will likely take longer, though. As I said already, you're only helping the users to get their tablet back faster and let the server do its job.

It doesn't pay to think of any server-side code before you have measured the pure wifi data copy time. And one advantage remains, when you do this from the tablets: The data at first is local to them, they read it fastest and with an SQL Server backend, any inserts causing triggers with cascading actions run server side already, you only have a disadvantage with a DBC/DBFs with complex triggers for referential integrity as this code is run on the tablets, too.

I actually assume you don't have such triggers and so I doubt a big advantage. Even just 1:1 copying over any data means the tablet drive reads it (doesn't matter if you share a folder for the server to get the files or a tablet process reads the tablet drive), then this is copied over wifi and stored in a server-side file, where the server-side process needs to read it once more. That part is not needing the tablet anymore, but if you can store the data in the server side database, be it DBC or SQL Server, you spare one cycle of writing and reading files, actually once you can make a direct connection to the server storing data into its final target is always fastest overall unless we talk of the unfortunate situation of how DVC stored procs are executed client side.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[AlastairP]

Hi Olaf,
I am considering doing just that - copy the mobile data to the server. However the requirement is for the techs to sync on the fly and sometimes sync only specific data.
But a full sync takes a long time and they may be required to do that while on duty.
So the time is important, and while they will be advised to to a full sync at end of day, there are other considerations.
Also there is a process to compare data so this is what takes the time for the tablet to crunch through.
A server side process is probably going to be a lot faster

Alastair

 

[Mike Gagnon]

AlistairP

Any reason you cannot address the remote server directly rather than synch(ing))?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[AlastairP]

Hi Mike,
The tablet users will be in the on site for extended periods where there is no internet connection. So they need to be able to edit offline data.

Alastair

 

[Olaf Doschke]

Still the initial question remains, if it turns out copying over all data takes most of the time, it doesn't pay to think of a server-side solution.

From the more detailed description now a reason is obvious. I don't know the details of the comparison, but if this is about changed data, you could make use of a timestamp or rowversion field in SQL Server and emulate that in VFP with a trigger changing an int to the next value whenever an insert, update or delete trigger runs.

That way you have it easy to just remember the reference state of the counter at the start of an offline session and get all changed data by filtering for versions higher than that. Make it like SQL Server, there is one central counter, not a version number per record. This works more like a lease number of the transaction logs.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name