Trouble using report listener accross a WAN

[jryan224]

I have an application in VFP9 which runs on a network server. Users launch the application from a mapped drive to that server. The current application uses a Lexmark virtual printer on the user's pc to create a .tif file to a different server on the network for processing to our electronic document system. A totally separate application manages the electronic document system. My application just has to create the files and get them to the right server.

I have modified the application to use the report listener to render the .tif files. I found I could not render to another server on our network; so I have the application render to the local pc and then copy the tif file to the network server. All development has been on my local pc.

I have now deployed this version of the application to the network server for an alpha trial by two people. One is a regular user of the application and the other is another developer in our group. My problem is the application will not even start on the user's pc - she just gets one beep. However; it runs fine on the other developer's pc.

I have eliminated network security/permissions as being an issue because I get the same result when I log into the network and run the application at the user’s pc. The difference I see is that the user’s pc does not have FoxPro 9 installed while the developer’s pc does.

Any ideas on what the user's pc may be missing in order to run the application using the report listener across the network? Installing FoxPro to the users’ pcs is not an option.

(I have been the sole developer on this application for the past 6 years and have seen it move from VFP5 to VFP 6 and from VFP6 to VFP9.)

Thank you for your help.

 

[TamarGranor]

Sounds like you need to put the VFP runtimes on the user's machine. Check out

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles~VFP

Tamar

 

[dgrewe]

Do not know the number of articles I've read that state "Never to run a Multi-User Database applicationa on the server."
Always write Multi-User applications a Client / Server Apps.
Always write the code to run on the local machine and pull the data from the server. The server can handle multi-user opening of databases but not EXE's.

LOL. I think a few of them were writen by Tamar Granger.


David W. Grewe Dave

 

[Mike Lewis]

Dave,

"Never to run a Multi-User Database applicationa on the server." Always write Multi-User applications a Client / Server Apps.

Can you clarify that.

Are you saying that you should never use a file server for databased applications? What about all our VFP apps that run against DBF files. How do you access those files without some kind of server?

Or perhaps you mean that the actual executable shouldn't reside on a server. I'd tend to agree with that, although there are cases when it might be appropriate.

But, in any case, that's a long way from saying to "always" write a multi-user app as a client-server app.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[dgrewe]

What I trying to say, is Never start a EXE on a Server that Runs on the servers drive. Place the EXE on the Local Computer and start it there and only access data from the server.

Write the program to do temp work and Local data file on the local computer. Never have the server do the work a local computer can do.


David W. Grewe Dave

 

[jryan224]

Thank you Tamar,
I had forgotten the runtime dlls.

 

[Mike Lewis]

Dave,

Thanks for the clarification. I won't start a discussion on the merits of always running the EXEs locally. But I would like to clarify ... what you are advocating is not a client / server application -- at least, not in the sense that most database folk use the term.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk