Programatically access files on local desktop from RDP and store file path in a variable - VFP

Hi, I need assistance with the question above. I'm developing an application for a doctor who does not want confidential patient information to be stored on Remote Desktop. The doctor wants to store the file path from the local computer on TS and whenever she wants to access the file it fetches from local computer using the path, opens on RDP but doesn't save it there - it's just for viewing purposes. If the application is accessed from another computer, the path won't be the same and therefore should throw an error.

Urgent help please.
You can also email me -
Really appreciate it.
Thank you.
Shamina MaharajSoftware DeveloperAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I know that Doctors don't like to be told what to do and/or how to do it, but you need to consider 'educating' them on how best to protect their patient's documents.

a doctor who does not want confidential patient information to be stored on Remote Desktop

Additionally you need to reverse your thinking on which computer is the "Remote' and which is the 'Central' one.  Your description above seems to confuse and/or reverse the definitions.

The computer where the application resides is the 'Central' computer.
All others (a.k.a. the various doctor's computers) are the 'Remote' computers.

From a document security perspective, it is much more likely that the single 'Central' computer can be set up to secure the patient documents than it would be to ensure that all of the various doctor computers were individually and adequately secured.  
You might want to 'educate' your doctors about that and help them to see the advantages of keeping the patient documents on a single well secured 'Central' computer.

Additionally, as one of my client's have done, you could create a VB.asp or C++ 'front end' for your application which would allow the doctors to not use the somewhat problematic RDP, but instead use their Browser to access the application which would then utilize the 'backend' FP/VFP data tables or even the more secure MS SQL data tables.

In spite of my believing that it is the wrong way to handle your needs and your doctor's needs...
Now as to accessing the Remote (doctor's) computer disk drives from the Central (where the application resides)
Any of the 'Remote' computers may be accessed from the 'Central' computer as:   \\tsclient\C\<distinct directory>   assuming that the Remotes have been set up to allow Shares.     Google for:   tsclient share

However, as you mention above, the individual doctor's may elect to save their patient documents into different directories on their own computers.
* One way to address this might be to make the application capable of allowing the individual doctors to enter their own settings into one of the application data tables.   Then if the application needed access, it would 'know' how/where to find the documents.
* Another way would be to 'educate' the doctors that they MUST all store their patient documents into the same 'standardized' directory on their own computer (example:   C:\PatientDocs\PatientName ) so that the application could ALWAYS find them with \\tsclient\C\PatientDocs\PatientName

After having worked with doctors in the past myself I know that your biggest challenge will be to 'educate' them as to how to work with your system.  Many of them will want to do things one way and many others will want to do things in a different manner.

Good Luck
You may configure the RDS connection to allow access to local computer resources, e.g. Printers and also disks and folders. If you do it then you may read the files from the program running on TS. The disk is accessible as e.g.  \\tsclient\D\  and you should see it after appropriate RDS session setup.

Remember the access is slow (as slow as printing from TS app) and I would strictly prohibit file writing this way. So copy the file into temp folder or into FoxPro cursor and then you may use it in the application.

Of course the app should be configured in a way which avoids the file existence checking when it is not necessary. So you should look at GETENV("CLIENTNAME") and at SYS(0) and configure the client's file name based on his computer name and/or login.

Update: Jrbbldr was faster :-)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I'll add one more thing to consider...

I initially forgot to mention that if any individual doctor accessed the 'Central' computer from one Remote (maybe an office desktop) on Day 1 and then from a different Remote (maybe from an at-home laptop) on Day 2, using their initially proposed patient document storage method, the documents from Day 1 would not be available to them on Day 2 - again highlighting one of the problems with the original patient document storage approach described above.

Good Luck
Shamina MaharajSoftware DeveloperAuthor Commented:
Thank you for your help guys. The company I work for hosts all their applications on Terminal server and our clients access TS to access our apps. We use VFP and VFP databases as it is the way our director wants things to be done - hence I cannot make changes to move to SQL or convince doctors otherwise - I can only suggest. Thank you for the feedback :) I really appreciate your time and effort.
The use of M$ SQL Server was suggested as just one of the possible ways to go.  
I was never trying to convince you to change to M$ SQL Server - merely letting you know that it was an option.

Regardless if you choose to use that or not (VFP is perfectly fine), you still need to think about where the actual patient documents will be stored.
The document storage method that you propose in your first posting here will most likely create nothing but trouble for the users.

If the application is accessed from another computer, the path won't be the same
Absolutely true.  
In fact not only will the path be different, but the Remote (doctor's computer) itself will not be the same.
That means that those documents stored on the 1st Remote will not be available from the 2nd Remote.

Regardless of which data table environment you choose (again - VFP is perfectly fine), you should be storing the documents on the Central computer so that they will be available to the designated doctor regardless of what computer they use to access your application.

Good Luck
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.