Hi Ed,

I wanted to thank you for your assistance and bring you up to date on the problem. First, the problem still exists unfortunately. However, I was able to get the program to run across the client's network when I copied the program to another computer, shared that new computer's program folder and accessed the program from a mapped drive on another computer. Interesting huh? Why will the program run fine across the network when another computer is acting as the server?

I checked with the client about the computer configuration again. There are four Win95 boxes. They appear to be using ipx/spx as their network protocol.

The program has run fine across the network for over two years, then, boom! it gives me the invalid library error on network computers, but runs fine on the computer that is acting like a server. Again, when I had the client copy the program to another computer and share that new computer's program file and map a new client drive from another computer, the program ran fine across the network.

At the present time, I am having the client clean up all of the computers of .tmp files, scandisk, optimize, re-boot, etc. I am at a loss why this problem is occurring. I have clients all over the state using this program across networks with no problem. I can run the program on my network, but when I send it to this client, the problem exists.

If you have any other suggestions of things I should try, I would appreciate it.

Thanks for your help,

TFISHER





>>Hi Ed,
>>
>>Thanks for the suggestion. I searched the computer for extra copies of FOXTOOLS.FLL and did not find any. I currently reference FOXTOOLS.FLL as follows:
>>
>>SET LIBRARY TO (SYS(2004)+"FOXTOOLS.FLL") ADDITIVE
>
>Correct - you'll point explicitly at the directory that the VFP runtime was loaded from - you can strengthen this even more by:
>
>SET LIBRARY TO (FULLPATH(SYS(2004)+"FOXTOOLS.FLL")) ADDITIVE
>
>which will result in an absolute path. Be very careful when using a mapped network drive here - if the drive mapping gets changed, the cute way of describing it is 'appy fall down go boom'; use a UNC rather than a mapped drive if someone forces you at gunpoint to not put the runtime on each local system...
>
>>
>>Is there a more preferred method that will provide an -absolute- path, yet not lock me down to a specific drive?
>>
>
>Within the confines of a given NetBIOS-compliant network, a UNC serves as an absolute pointer to a resource. A UNC is in the form "\\Server NetBIOS Name\ShareName"; only one machine at any moment can have a specific NetBIOS name in the context of an MS Network domain. If necessary, a different machine can be renamed to replace a specific server. On any given server, only one local resource can have a given share name, but the share name can be reassigned to allow you to point to a different local resource on the server throughout the network. A local resource can be a local folder, printer, shared storage devices such as tape or removable media drive
>or shared I/O device; it can also represent software services such as a database backend, mail server or the like which may be referenced by a UNC name.
>
>>Thanks,
>>
>>TFISHER
>>
>>>
>>>The odds are that the problem is a stray .FLL of the wrong version being found as a result of the modified Windows search path; the odds are it's running into a VFP copy of FOXTOOLS.FLL earlier in the search order of the Windows Search path than the FPW 2.6 FOXTOOLS.FLL
>>>
>>>A solution to this is to specify an -absolute- path for the FOXTOOLS.FLL file in your application, so there's no chance of a stray copy of the wrong version's FOXTOOLS being found.
>>>