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



On 12-Jul-2016 10:51 -0500, Darryl Freinkel wrote:
I have a procedure where I use the SQL PREPARE repeatedly on a file.
I need to close and open the prepared SQL statement to allow me to
select new parameters each time.

The program opens and closes the cursor many times as it runs.

1. How do I resolve the message?

Not having the full context of the condition, hard to know how best to explain either what is /resolution/ or what would need to be done either to prevent the messaging or clear the messaging.

But basically, the resolution is as alluded by the DSPMGSD SQL0501 QSQLMSG; i.e. do not attempt either to close or to fetch-from a cursor, that was either never opened or has since been closed.


2. Is there another way to do this?

The "this" is ill-defined; e.g. what is meant by "select new parameters each time", if even that quote represents "this", is neither intuitively nor conspicuously apparent to a reader -- not without some further explanation with perhaps some example included as [psuedo-]code snippets, showing what was or was not done in response to the sqlcode for each phase of processing. While seemingly dlclark infers "another way" is by reuse of the once-prepared statement per use of parameter markers, I am not entirely clear on how that relates directly to the Subject messaging, because, that the "program opens and closes the cursor" would presumably persist.?


I think this may be a warning message only. I think the code is
working, but I am trying to confirm this now.

The sqlcode -501 as "is not open" could be either an error or a warning, in the same way a -204 "not found" could be; i.e. a determination of which meaning, interpreted as warning or exception, is based upon how the application is coded, and how the application chooses to respond to the condition that was reported.


The problem is that it creates a huge joblog, that is not needed.


The OS offers the ability to remove messages; albeit most efficiently and easily, when the message that gets issued is directed\sent to the program performing the request. A spooled joblog shows some messaging context [even more context with second-level text included], such as the from-program and the to-program; if the to-program\procedure is that which issues the failing FETCH or CLOSE [and the from-program likely reveals which request, FETCH or CLOSE, as additional context], then the means to remove the message is quite simple -- if the messaging is deemed of no concern to remain visibly logged.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.