Re: Procedure using SQL doesn't work on second call

As Birgitta said, for embedded SQL access to the local database connection
state is managed automatically. No need to ever connect or disconnect.
Also, I believe the connectoin state is scoped to the the activation group.
Disconnecting will "break" all embedded SQL modules that may be invoked in
your the group.


On 7/13/07, BirgittaHauser <Hauser@xxxxxxxxxxxxxxx> wrote:

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