Re: Strange, inconsistent error in SQLRPGLE program

The SQL0104 message you see means that the SQL parser did not understand
the first thing it tried to read. It was not a token that an SQL statement
can start with. This means that what your application sent to SQL to be
processed was not recognized as a valid SQL statement.

This error is often seen when the CCSID for the dynamic statement does not
match the CCSID that the characters were typed in. Character host
variables used by SQL (SqlStmnt here) will take on the CCSID of the job
that is running the program. If your application is running in a CCSID you
weren't expecting, this could be a problem. The text you are using for
your SQL statement is in lower case. Lower case characters are NOT always
the same in every CCSID (290 for example).

If you think that CCSIDs could be your problem, I can think of 2 solutions.
Either type all your dynamic text using upper case or use the SQL DECLARE
VARIABLE statement to assign a CCSID to the variable you are using so the
job CCSID does not get used. You need to be a bit careful if you are
building a statement that has some hardcoded characters and some that are
coming from the workstation to make sure you don't end up with a mix of 2
CCSIDs in one statement - there is no way to make that work! Upper case is
my preferred solution. It will always be correct.

I'm not sure that this is the underlying problem, but it is worth checking
on.

Sue Romano
SQL Parser


-----Original Message-----
message: 9
date: Thu, 7 Feb 2008 11:59:09 -0500
from: <Lorraine.Ford@xxxxxxxxxxx>
subject: Strange, inconsistent error in SQLRPGLE program

All,



We have a client running a program which uses dynamic SQL to build the
SELECT statement. The statement under their conditions is very basic,
simply: SELECT * FROM MYFILE moved into a work field. Here is that
code:



SqlStmnt =

'select * from myfile';



Then the statement is prepared:



c/Exec SQL

c+ Prepare DtlDynSqlStmt

c+ From :SqlStmnt

c/End-exec



Here is where the strange and inconsistent error occurs. When they run
the program with this code in a processing stream of many programs, they
get SQL0104 on the prepare statement:



Message . . . . : Token *N was not valid. Valid tokens: ( END GET SET
CALL

DROP FREE HOLD LOCK OPEN WITH ALTER BEGIN.

Cause . . . . . : A syntax error was detected at token *N. Token *N is
not

a valid token. A partial list of valid tokens is ( END GET SET CALL DROP

FREE HOLD LOCK OPEN WITH ALTER BEGIN.



If they cancel the processing job, and run the program stand alone, they
don't get the error. They also don't get the error consistently when
running the program even as part of the processing stream, although they
get it frequently. None of our testers can duplicate the error, and
this is the only client getting this error in our client base. They are
on V5R3.



Has anyone encountered anything like this? It would seem that the
dynamic SQL statement is being corrupted somehow, but due to the way
they run this, a dump listing is not available to check the contents of
the field. Any thoughts are extremely welcome!!!



Thanks!