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


  • Subject: Re: SQL Question
  • From: "Nelson C. Smith" <ncsmith@xxxxxxxx>
  • Date: Mon, 9 Aug 1999 21:28:28 -0400

Thanks, I'll try that tomorrow.  I read about that parameter in the manuals,
but it didn't really seem to apply to my situation.  When I've got the job
in debug, each new Prepare says it opens a new ODP.  Some close cursors say
they close the ODP and some say they leave it open.  Either way, new keys
result in no data and no errors.  I'll try the delay parm.
-----Original Message-----
From: David Morris <dmorris@plumcreek.com>
To: RPG400-L@midrange.com <RPG400-L@midrange.com>
Date: Monday, August 09, 1999 2:05 PM
Subject: Re: SQL Question


>Nelson,
>
>I encountered same several years ago.  I found that changing the delay
>prepare parameter to *YES fixed the problem.  I tried to report this to IBM
>service.  They couldn't see that this was a problem and kept telling me
>how a prepare should be used.  Our conversations kept going in circles
>and I finally gave up.  This was about six years ago.  I finally gave up.
>
>I don't know if this is still a problem because I automatically use delay
>prepare now, but it is worth a try.
>
>David Morris
>
>
>>>> "Nelson C. Smith" <ncsmith@gate.net> 08/08/99 12:38PM >>>
>What is the proper SQL way to close a file (or an ODP) that has been opened
>with a Prepare, Declare Cursor, Open Cursor, Fetch, Close Cursor series of
>statements?  As I understand it, the close cursor statement doesn't close
>the file, thereby eliminating a lot of overhead on subsequent open cursors.
>This is good, but sometimes you might really need to close the file
>altogether.  I don't see any kind of SQL statement to do that.
>
>This is generic copy code used in procedures in service programs and even
>though the cursor is closed and the procedure goes away, the service
program
>persists and I am having problems getting rid of the old ODP when I need to
>change the keys in the Select Statement.  Blowing away the service program
>between calls with a RclActGrp command does fix the problem, but is
somewhat
>of a sledge-hammer method when I would like to have something a little more
>precise.  I would like to just close whatever the Declare established and
>not have the overhead of reinitializing the service program each time.
>
>A new Prepare and Declare doesn't seem to do it.  I get no data returned on
>the subsequent calls even though a message is returned saying "1 rows
>returned" and no error codes of any kind.  Apparently, it is trying to
still
>use the ODP established by the first Prepare and Declare.  Any suggestions?
>
>
>+---
>| This is the RPG/400 Mailing List!
>| To submit a new message, send your mail to RPG400-L@midrange.com.
>| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
>| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---END
>
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END



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