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