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

["Brian Johnson" <brian.johnson.mn@xxxxxxxxx>]

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.