C/A ODBC usage: Win2000 vs NT

[Guest.Visitor]

We had the same problem and there was 2 ways around it If the iSeries user and W2000 user had the same ID their password had to be the same. If they were different we created a DBGUEST user ID and PASSWORD on the iSeries and then embeded this into the ODBC link. IHTH George

[Guest.Visitor]

We're already using the second option you mentioned -- a specific iSeries User/Password embedded in the ODBC connection string. It works on NT, but not on 2000. Any ideas why not on the 2000 Server? Thanks.

[Guest.Visitor]

I take it the the ID on the iSeries is not on the W2000 network.

[Guest.Visitor]

The User ID is stored in 4 locations, all spelled exactly the same way: 1. On the iSeries, user profile 2. On the 2000 Server, user profile 3. On the C/A Express ODBC driver "connection options" "use default user ID, prompt as needed" field 4. On the connection string of the application program The passwords in areas 1, 2, and 4 are all the same. Of course option 3 doesn't let you key a password. Any ideas? Thanks.

[Guest.Visitor]

We put on the latest service pack to the V4R4M0 Client Access software. Still did not solve the problem, so we installed Hit Software's ODBC driver. The Hit driver worked great.

[Guest.Visitor]

The Client Access Express ODBC driver, or perhaps user/password caching, seems to behave differently on Win2000 Server than on Win NT Server. I have a web application (in IIS) that uses the ODBC driver on the NT or 2000 Server to connect to the AS/400. The application sets the User ID (UID) and Password (PWD) parameters of the connection string at the time it makes a database connection. The application works fine on NT Server, but on 2000 Server it appears to hang. When run on NT Server, it does not prompt for user/password, which is good because the application provides it. On 2000 Server I believe that behind the scenes somewhere, the ODBC driver is "asking" the application for the User/Password (but doesn't actually show a sign-in screen). Here are some additional details that may help: User "Chris" is currently logged onto the NT Server. The ODBC driver's Connection Options are set to "Use default user ID, prompt as needed: BCSWCUSER". (BCSWCUSER is what the application attempts to connect with.) I downloaded from TUCOWS a little application called "SQL Runner" that allows me to connect to an ODBC DSN and issue an SQL SELECT statement to test things out. SQL Runner has the option of supplying a user/password at db connection time. On NT Server, when SQL Runner is started and its user/password fields are left blank, the ODBC connection works just fine with no prompting for user/password. The 2000 Server's ODBC DSN is setup the same way as on the NT Server. SQL Runner was also installed on it. On 2000 Server, when SQL Runner is started and its user/password fields are left blank, the "Signon to AS/400" Client Access style user/password prompt is shown. This doesn't happen on NT Server. As a matter of fact, the "Signon to AS/400" prompt is shown TWICE. After the additional signon prompts are filled in, the SQL Runner results come up OK. Any idea why 2000 Server is acting differently? Any way around this user/password prompting? If password caching is the issue, how do I get the 2000 Server to cache the BCSWCUSER and its password? Thanks for your help.

[Guest.Visitor]

Turns out that although the V4R4M0 w/latest service pack didn't solve the problem, V4R5M0 w/latest service pack DID solve the problem.