VB Exe fails in ADO connect to AS400 w/ 80004005

[avanderlaan]

I have a VB app that is "well-behaved" when running in the Visual Studio IDE. It connects to the AS/400 w/0 problems. When run as a standalone executable, the "Open()" method returns the error 80004005 ("Unspecified error&quot from provider=source. The VB installation is VB6(SP/5), Win2K(SP3), MDAC 2.6 and SQLServer 2000, most recent SP onboard the development machine. The EXE connects correctly to the AS/400 from a laptop with the same Windows configuration except for SQL Server. All help is gratefully appreciated.

 

[chiph]

I would check your ODBC configuration. Perhaps the connection is spelled differently.

Chip H.

 

[avanderlaan]

chiph,

I don't think that the ODBC config changes. When I run the code from VB6 development environment it connects correctly. The problem occurs after I "Make the Executable" from the code. Thanx.

 

[chiph]

Sometimes VB gets confused when building EXEs. Try deleting the old EXE, and any .pdb files. Then rebuild.

If you're using COM binary compatability, doing this will break compatability.

Chip H.

 

[avanderlaan]

Chip,

I deleted the old EXE and the .pdb files, and then rebuilt. I am not relying COM binary compatability since this app is still in development. I also verified the ADO object references as using 2.5 TLB (even though MDAC 2.7 is installed on the development machine). Still no luck.

Yesterday after work one of the IT guys suggested deleting and recreating the DSN as a last resort while we were walking out to the parking lot -- and it worked!

Thank you for all your thoughtful comments, tips and brain time. Any thoughts on why the DSN wasn't quite good enough?

 

[chiph]

Any thoughts on why the DSN wasn't quite good enough?

No idea. It's been a while since I used DSNs (and AS/400s!), but I seem to remember the ODBC configuration being a little flaky sometimes. We supplied a small communications test applet with our product that the customer could run to verify connectivity. They usually ended up calling us anyway, but it cut down on *some* support calls, anyway.

Chip H.