Hi All,
I have a basic VFP Com server (psi.dll) that provides an interface to my VFP Data to a 3rd party application. On the computer where the data resides (file server), it works fine, the data resides on the local C: drive.

On networked client computers, the VFP data is normally accessed via a mapped P: drive. This access does not work from the VFP Com Server (psi.dll). My regular VFP Desktop App accesses the data via the P: drive just fine.

It looks like the VFP Com server does not know anything about the P: drive, or does not have access. My ErrorLog indicates the VFP Com server cannot see the P:\products.dbf file. I think this is a security issue, and the mapped P: drive is associated with the current user, but is not available to the VFP Com server.

So my question is, how do I grant a VFP Com server (MTDLL) access to networked VFP Data? Is this possible? The 3rd party app calls a small Visual Basic executable and passes two parms: InputFile.txt and OutputFile.txt. The Visual Basic executable then calls the VFP Com server (psi.dll) and passes the two files as parameters. My VFP Com server reads the InputFile.txt and retrieves the requested information from Products.dbf and returns the info via the OutputFile.txt.

TIA,
Steve

What is hosting the DLL? The process that is instantiating determines the security context (Identity) that the server is running under.

It sounds like this may be a server (IIS?) or some sort of service, which won't have access to your user context. IOW, if the host process is not in your same user context it'll know nothing about your mapped drive.

In that case you have to explicitly map the drive as part of the application (it's a simple Windows API call but you need credentials to do it) or have some mechanism like a logon script that maps the drive in the correct context for that user.

+++ Rick ---

Thanks Rick! That makes sense. It's a small Visual Basic program that actually instantiates the VFP Com server. The VB.exe is called via a 3rd Party Web Page but there's also an Agent that runs as a Service on each computer. So, I think the Agent Service is what actually calls the VB.exe, which calls the VFP Com server. I think they went the Agent/Service route because the 3rd Party App was a Desktop App for 20+ years. This (Agent/Service) minimizes the changes required by vendors like me whose software needs to interface with their product. Here is the flow:

Web Page > Agent Service > VB.exe > VFPCom.dll

So, I think the security context is Local System Account, which is what the service logs on with. Based on your previous response, it sounds like within the VFP Com Server, I can connect to the Share where the VFP Data resides via a Windows API call, and I will need to provide logon credentials as part of the API call. I think this is the approach I will try.

Thanks for the feedback and insight Rick!

Sounds to me the VB.exe is the one, but it'll likely live in the same Identity context as the Agent service because it's launching the VB.exe. If it's a service - look at the service registration and what account it's launched as. That's the account you likely want.

+++ Rick ---

Thanks Rick! I decided to go with the Windows Scripting Host approach. I've used the Scripting Host before, but it's been a long time (back in the Server Admin days). I had forgotten how handy that utility is. All it took was a couple lines added to the VFP Com server to map the drive, then a couple more lines to confirm access to the file. Easy!! It's now working, and I can move on to other projects, like getting back to the web interface I've been toying with for years.

One of my clients has requested a phone interface for their mobile techs, specifically to enter their time/hours while in the field. I have downloaded the TimeTrakker App and hope to use it as an example/template. Excited about getting back into some WWWC development!

Thanks again!
Steve