>I am using WNetAddConnection to temporarily map to remote drives, gather some various file info, then disconnect using WNetCancelConnection. Everything works wonderfully, most of the time. I OCCASSIONALLY receive an error (1326) from a few of the remote resources, but not always the same ones and not consistently. (I have an input form that has a cmd button that allows the user to immediately "test" the resource they have specified.) Today I tested one that has sometimes given me problems and received an error (again 1326). I went to a DOS prompt, performed a NET USE (with the exact same info I use in the API call) and it connected fine. I disconnected, went back to my form, clicked the test button and it connected fine. The application is running on NT Workstation 4.0 and is attempting to map to resources running the same OS.
>
>Does this sound like some type of timing issue? (A few of the remote drives have a persistent map and they have NEVER failed to connect.) Is there something I am missing?
>

I've seen this most often where someone is attempting to access a resource controlled by a domain, on a machine that they happen to have an account on as well, and their domain privileges exceed their local account privileges. I have no idea why the NET USE would work unless you need to set the userid/password context, functionality which is not provided by WNetAddConnection() (you need WNetAddConnection2() to get this).

If your environment has Windows Scripting Host installed, you can use the Wscript.Network Automation Object's MapNetworkDrive method, which allows optional specification in the method call. I'd invoke it as:

oWshNet = CREATEOBJ('Wscript.Network')
ox.MapNetworkDrive(cLocalDriveLetterColon, ;
                   cRemoteUNC, ;
                   lOptionalMakeThisAPermanentMapping, ;
                   cOptionalUserid, ;
                   cOptionalPassword)

Failing that, you'll need to use WNetAddConnection2(), which requires a pointer to a NETRESOURCE structure, as well as both password and userid. The NETRESOURCE structure contains several embedded pointers to strings, and is most easilty handled with a C style .DLL wrapper, although you could kludge it together using API calls to allocate and deallocate the string memory and populate it with StrCpyN, and then deallocating the buffers afterwards yourself - you do not need to read the NETRESOURCE as a returned structure.