I needed to inspect some tables in both a test and production DB2 databases this morning. Fortunately, WebSphere Studio's Data perspective provides an easy way to do this. (I won't go into detail about how to do this here. For more information, please consult Chapter 6 of the IBM Redbook titled "WebSphere Studio Application Developer Version 5 Programming Guide".)

Before I get any further along, I should mention that the name of the database is the same in test and production. For confidentiality purposes, I'll refer to the name of the database as "SOMEDB".

Since I'd previously installed a DB2 V7.1 server on my laptop, I didn't need to do anything to make the IBM DB2 ODBC DRIVER available within my ODBC Data Source Administrator. I went ahead and created a new ODBC connection to SOMEDB on the test DB2 server, using SOMEDB as the Database Alias. After sampling the contents of several tables in the test database, I was ready to take a look at the same tables in the production database.

When I went to create an ODBC connection for SOMEDB on the test server, SOMEDB already popped up in the combo box of Database Aliases. Not realizing what this meant, I typed in SOMEDB as the database name and clicked the [new] button to create a new alias. I went through all seven tabs in the Add Database Wizard, and when I clicked on the [Finish] button, I got this nice message box:

The add database operation failed.

SQL1005N  The database alias "S697U" already exists in either the local database directory or system database directory.

For additional information, press the help button. Correct the problem described in the help message and retry.

I cancelled out of the wizard and pondered what to do. I decided to search through Google for "SQL1005N" to see if that could be of any help. While I didn't find a page that related directly to my problem, I found one that helped me to figure out how to solve it. It seems that when you add an ODBC connection to a DB2 database, the connection is also added to your DB2 client configuration. All I needed to launch the DB2 Control Center and remove the server definition from there:



After that point, I was able to create the ODBC connection for the production server no problem. Now, some of you may be saying, "why didn't you just use the DB2 Type 4 driver?" Well, I did have a V8 JDBC driver file and license file on my laptop, but I don't think I had the correct port to use for a JDBC connection. If that had worked, I could have avoided this whole scenario entirely. There's another good reason for using JDBC!

No comments.