This may be of no help at all as I've only used SQL for local access in
C programs - but have you tried looking at the CLOSQLCSR parameter on
the CRTSQLCPPI command? If you have it set to *ENDACTGRP then as long as
your activation group stays active it should only 'soft close' the
cursor that you close. I am not sure how this works on remote databases
but I imagine it somehow would have to work in conjunction with whether
or not the connection stays open. It looks like remote connection types
are affected by what you put on the RDBCNNMTH parameter of the command.
The default is to not disconnect (but it doesn't mention anything about
how a connection left connected would be reused).

What I can't tell from your note is when you say you are re-running the
program does this mean you are starting a new job for each time you re
run it or are you just calling your program again and again from the
same job and - from the same activation group? You might also want to
make sure you don't do a CRTPGM with Activation Group *NEW or it will
definitely not be good for performance and the close cursor when the
activation group ends will be just the same as ending the program. . . 



message: 1
date: Tue, 12 Jul 2005 09:43:58 -0400
from: "Steven" <steven@xxxxxxxxxxxxxxxxxxxx>
subject: [C400-L] SQL Connection Management


How are connections to remote databases managed when you use static SQL
ILE C/C++?

I have a simple program that contains the "declare cursor", "open
"fetch" and "close cursor". When the module is processed with CRTSQLCPPI
specify the information for a remote database. This single module is
use to create a PGM that is called directly.

The program runs fine but it seems like a new connection is created
time I run the program and that the previous connection is not ended.

1. Is this behavior normal?
2. When will previous connections actually be ended?
3. What should I do if I wanted the end the connection?
4. How can I reuse one of these previous connections?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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

This mailing list archive is Copyright 1997-2022 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.