Re: Tracing SQL0901 Error in iSeries Access ODBC Driver

Found my problem. The stored procedure that I'm calling is processing
the variables as XML documents. My real issue is that one of the
documents passed in needs to allow for a great deal of data. While
testing in the interactive environment, I could pass it as a native
varying length value. From SQL, however, the maximum length is too
large for varchar, so I had to change the underlying RPGLE program to
accept CLOB values. Herein lays the problem.

When I pass the values as CLOB to the xml parser via xml-into, I'm
receiving xml parser errors. If I convert the CLOB values to native
varying length strings, the strings include extra characters at the
beginning which also cause parser problems.

Besides removing functionality by reducing the maximum length of the
data passed, does anyone have any suggestions on how to successfully
parse the CLOB data?

Tom Armbruster

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Armbruster, Tom
Sent: Tuesday, December 18, 2007 10:31 AM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Tracing SQL0901 Error in iSeries Access ODBC Driver

I'm not really sure for which list this question is suited, but I'll
post here as it is a web related issue.

Background info for the question: We're currently in the process of
designing a major release for our product. The new release has been
designed in libraries separate from our current production release. Our
web site is a ColdFusion application which resides off site and
successfully operates via the iSeries Access ODBC driver when calls are
made to the current production library.

Now, the problem. I have a stored procedure defined in the new library,
and I've created a specific user profile and job description for a new
ODBC connection from the web servers. When the procedure is called
using this new login, the call generates a general SQL error - SQL0901.
I can access the data library without issue, but the not the stored
procedure.

I've tested the procedure using the current user profile for the site
which has authority for our production libraries. I can successfully
call the procedure, but the user profile doesn't have access to the
development libraries. This, of course generates an error in the RPGLE
program that the procedure calls.

I'm assuming that the problem with the new profile is probably a simple
authority issue; however, I can't seem to produce a job log or a
detailed trace that will display more detail. Any suggestions on how to
trace the source of the SQL error?

Tom Armbruster