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

I'll try to explain how SQL works:
1. When executing an SQL statement an access plan must either be built or at
least validated.
In the access plan the indexes to be used and temporary objects (such as
hash tables, bitmaps, relative record lists) to be built for to open the
data path are desrcibed. In this step all access paths (in either DDS
described logical files or SQL indexes) will be checked and the statistics
will be consulted.
2. After the access plan is built, validated and actualized the temporary
objects will be created and filled with data, that can be accessed, i.e. the
access path is opened (ODP).

Both steps are very expensive and should be avoided whenever possible.

After the first execution the ODP will be completely deleted.
With the next execution step 1 and 2 are executed again. If the ODP is
reuseable the temporary objects will not be deleted after the second
execution. (That's why the files stay open) When executing the CLOSE
statement only a soft or pseudo close will be executed. For all subsequent
executions of this SQL statement (at the OPEN statement), step 1 and 2 will
not be executed again, but only the data will be actualized.

When compiling your (service-)program or module with the option CLOSQLCSR
*ENDMOD, the ODPs will be hard closed as soon as the module will be
finished. But for all subsequent exeuctions always full opens (step 1 and 2)
must be performed that will decrease performance considerably.

When using activation group *NEW, the ODP gets hard closed at the end of the
program, even if the default value CLOSQLCSR *ENDACTGRP stays unchanged,
because the activation group ends.

BTW if you specify tables or views unqualified and change the library list
or use OVRDBF and DLTOVR for these tables or views the ODPs get hard closed.

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 AGlauser@xxxxxxxxxxxx
Gesendet: Monday, April 09, 2007 18:23
An: RPG programming on the AS400 / iSeries
Betreff: Embedded SQL in an RPG *SRVPGM, file stays open


Hi all,

I hope this is the right place to ask this question. I've looked at the
Embedded SQL Redbook a bit, as well as archive.midrange.com, but I haven't
found anything. I'm sort of making baby steps with embedded SQL at this
point, so it's quite possible I'm not looking in the right places.

My problem is that the PF stays open after my SQL statement is run, even
if I add a CLOSE. I understand from the Redbook that the SQL preprocessor
creates it own F-spec for each file it uses, so I can see why the close
isn't working the way I'd hoped. Is there some way to force the file to
close after the SQL statement?

My code looks like this:
P DSRMUNITS_getUnitByAssocUnit...
P B EXPORT
D DSRMUNITS_getUnitByAssocUnit...
D PI LIKE(vuUnit)
D assocUnit LIKE(vuUnit)
D CONST
D errorInfo LIKEDS(UTTERRDS_errorDS)


D* Local fields
D retField S LIKE(vuUnit)

D MORE_THAN_ONE_RECORD...
D C '21000'

C/EXEC SQL
C+ SELECT vuUnit INTO :retField
C+ FROM dsp070
C+ WHERE vuAss = (SELECT vuVMU#
C+ FROM dsp070
C+ WHERE vuUnit = :assocUnit AND
C+ vuStat IN ('OTR','AVL')
C+ )
C/END-EXEC

/FREE
errorInfo.errorCode = DSRMUNITS_NO_ERROR;

if (retField = *blanks);
errorInfo.errorCode = DSRMUNITS_UNIT_NOT_FOUND_ERROR;

elseif (SQLSTATE = MORE_THAN_ONE_RECORD);
errorInfo.errorCode =
DSRMUNITS_ASSOCIATED_TO_MULTIPLE_UNITS_ERROR;

endif;

close DSP070;
return retField;

/END-FREE
P DSRMUNITS_getUnitByAssocUnit...
P E

TIA,
Adam

Attention:

The information contained in this message and or attachments is
intended only for the person or entity to which it is addressed and may
contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this
information by persons or entities other than the intended recipient is
prohibited. If you received this message in error, please contact the sender
and
delete the material from any system and destroy any copies. Thank you for
your
time and consideration.

Attention:

Le contenu de ce message et(ou) les fichiers ci-joints sadressent
exclusivement ` la personne ou -entiti ` laquelle ils sont destinis. Ils
peuvent
contenir de linformation confidentielle, protigie et(ou) classifiie. Il est

strictement interdit ` toute personne ou entiti autre que le(la)
destinataire
privu(e) de ce message dexaminer, de riviser, de retransmettre ou de
diffuser
cette information, de prendre une quelconque action en fonction ou sur la
base
de celle-ci, ou den faire tout autre usage. Si vous avez regu ce message
par
erreur, veuillez communiquer avec lexpiditeur(trice), supprimer ce message
et
les fichiers ci-inclus de tout systhme, et en ditruire toutes copies,
quelles
soient ilectroniques ou imprimies. Nous vous remercions de votre entihre
collaboration.




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.