Working and running VFP Application on Mapped Network Drive vs Remote Desktop Protocol environment

[vj]

hi everyone,

i'v implemented VFP application that is located on each client machine and connects to the server where my applications data folder is located which contains all the tables and .dbc ... but these are just small LAN environment setups with around 10 to 15 computers ...with no problems and no issues ... however Iam recently looking at an application that sits on the server and all the remote clients connect to the application via RDP.
I'v noticed and find it very interesting ... that this is a very good way to do things ... 1 very big advantage I find is that if any changes have to be made .. only the .exe file on the server has to be managed becoz all the clients are using just that one app via RDP .... where as in the earlier case .. the app on all the client machines have to be managed becoz every one is running .exe locally on their machine !
But however I'v also noticed one big problem regarding the app running in the RDP mode ,,, which is that sometimes the app seems to just freeze and stay stuck for a very long time .. sometimes forever .. and the session has to be killed ! has anyone come across this problem ... and by-the-way ... what do you guys have to say about the two modes of running the app .. pros and cons !

thankx
Vijay

 

[GriffMG]

Hi

For your local area clients, you should probably try and implement a process where you run a 'stub loader' which looks for newer versions
of your live application, downloads them if needed, and then runs the main app. It can get a bit messy in newer versions of windows, because
when your updater is 'elevated' it might lose drive mappings... but there are always ways around that.

Personally, I am not such a fan using remote sessions for apps, but sometimes it is the way to go. Printing is often the bugbear, slow and unreliable.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[GriffMG]

faq184-4492

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[JRB-Bldr]

Remember than from the perspective of the application running, an RDP session is basically no different than a 'standard' method of running.

Again, from the application's perspective, it is just running on the virtual workstation (the RDP 'workstation') just like it was running on the non-virtual workstation.

The biggest difference is in the RDP session itself.
* Do the virtual workstations have enough resources (memory, processing power, etc.)?
* Does the user's workstation have enough bandwidth to successfully handle the RDP data flow.
* What other applications does the user have running that might be affecting the RDP data flow.

I too have had some users 'lock' up when running in RDP mode, but others ran consistently fine.
In general the lock-up users were pretty remote (different cities, etc.), with their RDP running across the internet (subject to numerous Comcast cable bandwidth variations).
The in-house users who were running the VFP app via RDP seldom (if ever) encountered problems.

1 very big advantage I find is that if any changes have to be made .. only the .exe file on the server

For that issue I use an Application Launcher (a version of faq: faq184-4492) which enabled me to re-compile the client's EXE on the server at any time needed and not require the users to all get out. Not only does it 'separate' the user's run-time version from the server version, but it will also automatically update the user's version when changes are detected.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

In general, you'll always get better performance if your executables (and related resources) are held locally, on the user's physical hard drive. Also, you're less likely to encounter the sort of freezing that you mentioned.

You're right about the problem with updates. Many developers solve that by havng the local executable check a central location for new versions, along the lines that Griff described. For my own apps, I use a system where the loader polls a web server, and invites the user to download a new version when one becomes available. This works well.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads