× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



BTW, the easiest way to catch this type of problem is to put the job in
debug mode and put a watch condition on the variable.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: Thursday, February 07, 2008 11:41 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Strange, inconsistent error in SQLRPGLE program

The only thing I can think of is that SqlStmnt gets accidentally updated
by other program. This could be cause by parameter or parameter length
mismatch between program call.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Lorraine.Ford@xxxxxxxxxxx
Sent: Thursday, February 07, 2008 10:59 AM
To: rpg400-l@xxxxxxxxxxxx
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!



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.