>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.
>>
