This was a problem in VFP 7.00 and I am still having problems even in VFP 8.00 !*&^%$

Ed was talking about this problem in VFP 7.00 but never wrote the fix :(

I am trying to upsize a very simple file across the network and I am getting a

Error #202 in genbulkinserttextfile(0):Invalid path or file name

Has anyone fixed this buggy wizard yet :(




Ed wrote the following.

>>The new Visual FoxPro 7.0 SQL Server Upsizing Wizard Update has the following bug. When i excute it from network drive (Map drive Z: for example) i get Error "Error #202 invalid path or filename in genbulkinserttextfile line 1971"
>>
>>The old code (wizusz.prg) was :
>>lcBulkFileNameWithPath = SYS(5) + CURDIR() + BULK_INSERT_FILENAME
>>
>>and now the code is :
>>LCBULKFILENAMEWITHPATH = "\\"+ADDBS(ALLTRIM(LEFT(SYS(0), AT("#", SYS(0))-1)))+STRTRAN(SYS(5), ":", "$")+CURDIR()+"BulkIns.out"
>>
>>for network drive this return an error!
>
>That makes complete sense, since there is no guarentee that the mapped drive letter will translate into a sharename for the machine it's running on, which is what you're requesting here. The code is fatally flawed working from a mapped drive letter, for the simple reason that you're trying to form a sharename using the name of the local machine you're running on (the SYS(0) portion of the code) and the mapped drive letter, which is not a local resource.
>
>To fix this requires either the use of an API call to translate the drive letter into a valid UNC (the API call WNetGetConnection() is documented in both the FAQ and in the Win API sections here on UT, which can translate a mapped drive into a valid UNC) or the use of an external COM component such as the Scripting.FileSystemObject from the WSH (described in detail in a 5 part article on www.vfug.org, written by George Tasker and me) to translate the drive letter into a UNC-based path. Worse, if you've accessed a share without mapping a drive letter to it, SYS(5) does not return what you expect.
>
>The solution is to determine if the current directory is a network drive using the new DriveType() function in VFP7, and if it is, translate the drive letter to the appropriate UNC and append the result of CURDIR() to the UNC of the mapped drive. You have to translate mapped drives to their UNC form, since the drive mapping may not share the same mapping as in effect in your user session.
>
>I'd suggest using DriveType() and the WNetGetConnection() API call as documented here in the Win API section as the most portable way of altering the code, since it's not guarenteed that the machine you use has the necessary COM components installed.
>
>No, I'm not going to write it for you.