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!

No comments.