× 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.



Hi,

Please check SQLCOD or SQLSTT after each call.
If SQLCOD is negative an error occured. From the SQLCOD you can determine
the message id in the message file QSQLMSG.
Message-Id: SQL+ Absolute value of the SQLCOD.
For example: SQLCOD -811 --> Message-Id SQL0811

But I think the problem is the Disconnect Statement. (Just remove it!)
The first time an automatic connect to the database occurs, but only the
first time.
After execution you disconnect all. But it in not connected any more.
Why do you do it?

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von James Rich
Gesendet: Friday, July 13, 2007 02:35
An: rpg400-l
Betreff: Procedure using SQL doesn't work on second call


Hi list,

Well I'm up against more SQL trouble that I can't figure out. I've
written a procedure that uses embedded SQL. This procedure is part of a
module that is used as part of a service program. When this procedure is
called the first time everything works beautifully. But on any subsequent
call the SQL code fails to return any results - even with the same
selection criteria. I've searched for anything that could be the cause
and have found nothing yet. So I turn to the collective wisdom of the
list :)

I've posted the complete code to this procedure at:
http://code.midrange.com/index.php?id=f43dc0e96e

Yes, it is fixed format. Sorry about that.

Notice that I've even tried redundant CLOSE C1 statements trying to find
the point of failure somewhere.

This is compiled with:
CRTSQLRPGI OBJTYPE(*MODULE) COMMIT(*NONE) CLOSQLCSR(*ENDMOD)

Can someone please explain to me why the second and subsequent calls to
this procedure give zero results?

James Rich

It's not the software that's free; it's you.
- billyskank on Groklaw

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.