The upgrade of the Domino server that was causing my LSX agent to fail took place yesterday. (Thank you, valid backup tape!) I used the NotesAgent.RunOnServer() method to run the agent manually, and it worked fine. Whoo-hoo! I'm happy that I can finally mark a problem that's been hanging around since 7/26/04 as resolved. Thanks to the corporate Notes support staff to agreeing to upgrade the Domino server software.

(0)

The upgrade of the Domino server that was causing my LSX agent to fail didn't happen yesterday. It seems like there wasn't a current or valid backup of that server available beforehand. So, the upgrade has been delayed until further notice.

(0)

The production Notes server where the problem has been occurring will be upgraded to 6.5.2 on 9/12. Hopefully, the LSX problem I've been experiencing will go away at that point.

(0)

I received some very positive feedback from the Notes application support group at the company where I experienced the LSX error. They confirmed that the error was confined to Domino servers running code prior to 6.0.3. Interestingly enough, they were able to get my code to run just fine by commenting out the line where the error was being generated:

Call con.Action ( LCACTION_TRUNCATE )

So, I guess I have to figure out if I want to rewrite this statement as a while loop that deletes all existing record in the tables one at a time. Yeesh.

The support group also let me know that Domino 6.0.3 and 6.5.2 use a new LC LSX API. When I didn't see anything on this in the 6.0.3 Release Notes. I asked them how they knew this. They replied that they learned this when speaking with a Lotus rep on an unrelated DB2 LSX issue.

(0)

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!

(0)

I decided that it was time for me to continue my DB2 LSX troubleshooting exploits at the customer site. The obvious advantage of doing this was that I would be able to access the DB2 database directly through the network using WebSphere Studio. After fighting may way through a few DB2 configuration problems, I was able to use WSAD to verify that the table the Domino server is telling me does indeed exist in the target database. I was also able to use the WSAD SQL Query Builder view to insert and delete records from the table in question, thereby verifying that the level of access the userid being used by the Lotusscript agent is correct. As a final sanity check, I ran the agent manually using my Notes 6.0.3 client, and it ran successfully! I can't tell you how relieved I was. I was beginning to think that my eight years of professional Notes/Domino development experience were all for naught.

At this point, I believe the problem is due to the version of the Domino server that is being used to run the agent on a scheduled basis. The development Notes server I have been using is at 6.5.2, while the production server is at 6.0.2CF2HF371. Since the agent runs fine with 6.0.3 and 6.5.2, I suspect that there is a problem with the core server code used on the production server. For some reason, executing the following statement:

Call con.Action ( LCACTION_TRUNCATE )

using a version of Notes/Domino prior to 6.0.3 always generates this LSX error:

Error 12545 occurred in INITIALIZE at line 48: Error: Metadata object 'tablename' does not exist, Connector 'db2', Method -Action [Truncate]-

Emboldened by my discovery, my customer proposed speaking with the member of the Notes support group who created the DSN on the development and production boxes for me. Fortunately, he was in today and at his desk when I called. He said to come right over. After we arrived, he double-checked the DSN on the production box was correct and that the userid and password I've been using is accepted. He also verified that the sql.ini did not need to have an entry for the target DB2 server in it.

My support contact agreed to research the problem I described to him further, provided I create a Help Desk ticket for him to track the work. He also said that he'd use Teamstudio Delta to verify that the code used by the agent in development and production is the same. I could understand his point of view, as I'd hate to spend hours researching a problem, only to find out that it was due to a coding change that exists in one location and not the other. Hopefully, I'll have more to report on this problem next week!

(0)

I pleaded my case to the Help Desk yet again, and the response came back that they do not support mentoring and they consider this issue mentoring. Now, I don't claim to know everything there is to know about Notes development, but I'd like to think I'm beyond the mentoring stage at this point in my career. The response I received back by e-mail included information regarding who to contact about hiring a developer, which included the contact information for my own boss, Walt Seymour. This gave me the biggest laugh in some time, I have to say.

I'd hazard a guess that my ticket isn't getting to anyone who knows anything about Notes programming. The reason why I say this is that I know most of the people who provide Notes development support for this particular company, and I doubt any of them would send me Walt's information.

(0)

I decided to take the Help Desk up on their offer, and created a new agent that runs the sample code provided in the LSX Examples db. To eliminate the possibility of coder error, all I did was change the database, username and password settings in the code. I ran the code, and it still generated the same error.

08/02/2004 01:44:55 PM Agent message: Error: [IBM][CLI Driver][DB2/SUN] SQL0031C File "C:\32CAE614\bnd\db2clish.bnd" could not be opened., Connector 'db2', Method -Catalog [Metadata]- (-31)

Heavy Sigh

As before, the code I'm trying to run is viewable by clicking on Read More below.


(0)

I contacted the Help Desk about the problem I was having trying to execute the LSX Catalog method, and the response I got wasn't very helpful. In essence, the Help Desk referred me to a Notes db containing some LSX sample code. If I needed any help beyond that, it would be considered mentoring. Great.

(0)

I'm trying to use the LSX LSConnection.Catalog() method to list all of the tables in a DB2 database. So far, all I get is this funky error:

Error 12325 occurred in INITIALIZE at line 94: Error: [IBM][CLI Driver][DB2/SUN] SQL0031C File "C:\32CAE614\bnd\db2clish.bnd" could not be opened., Connector 'db2', Method -Catalog [Metadata]- (-31)

which I have no idea what it means. If you'd like to see the Lotusscript code behind the error I'm getting, click the Read More link below.


(0)

I asked the DB2 dba to verify that the "schema.tablename" exists in the production database. He said that it did, and also that the production server is still running V7.1. The server is targeted to be upgraded this Sunday, so I'm wondering if the upgrade will resolve this problem.

The DBA also asked me if there was some way that I could verify what tables I can see on the Notes side. I've used the LSX Catalog method to take a look at tables and stored procedures in Sybase previously, so hopefully I can do the same with DB2.

(0)

I've written a scheduled agent that uses the DB2 LSX to export data contained in a Notes database to a DB2 database. For some reason, my code is able to connect to the DB2 database just fine. However, when the second statement below:

con.Metadata = "schema.tablename"
Call con.Action ( LCACTION_TRUNCATE )

I get this LSX error:

Error 12545 occurred in INITIALIZE at line 48: Error: Metadata object 'tablename' does not exist, Connector 'db2', Method -Action [Truncate]-

I'm not sure what to do about this error, as the same Lotusscript agent runs fine on a test Notes server when hitting a test DB2 database.

(0)