we had this very dirty problem last week, which I want to share with you guys.
We have this
VB program that, on a daily basis, downloads shipments and bookings information from our common AS400 system into diverse local PC databases. This info is linked to user-entered forecast, which is uploaded every evening for processing on the AS400.
This program (that has ran for several years) holds a routine which reads an AS400 file holding our financial calendar. The routine checks if next year's calendar is set up there, and if so, downloads it into Access. This routine uses an ODBC-linked table in the Access database. (We can't use the IBMDA400 provider, since the Packed AS400 fields are EBCDIC, and translation to ANSI/ASCII ain't supported there).
Last week, some new functionality was added to the updates program, and I recompiled it. Because I wanted some parallel runs, I named the program 2003_updates.exe.
And then the problem begun : the calendar-routine suddenly started failing, returning the error stated in the title of this thread. We started checking the ODBC drivers, the Client ACCESS (our emulater package) setup, the ADO and DAO versions...
Then, we found out that, on my machine, where I had written and tested the source, the program failed as well.
I started debugging the source, only to find out it worked smoothly in debug. So we started adding pointers etc. Then compiled as test.exe. Eureka, it ran. So we copied that new exe to the remote location. AND! It ran ok!
Where-upon I renamed it in the remote location, to 2003_updates.exe. AND! It failed again. Copied it back over to my machine. It failed! So I renamed the exe into test.exe, and it ran!
Then, we started renaming other applications, and found out that any app, using the MSDASQL provider, or ODBC in general, to connect to our AS400 system, would fail if the first char of its exe name was changed into a numeric character!!!
So, did or didn't we find some kind of bug?