SQL Connection Issue

Background... We have an SQL standard error utility (we created)
that logs diagnostic information and messages on behalf of the calling RPG
problem program from both parameter input as well as automatically from
the joblog into the LOG4ILE table (supplied by IBM as part of their
standard logging facility). That worked for several months. But, then we
had to modify our SQL error utility to handle the situation where the
problem program was actually connected to a remote database. In other
words, our utility needed to connect back to the local database in order
to log the requisite messages. We used the CONNECT RESET statement in
order to accomplish this. This change has been working that way for quite
a while, now (years).

Currently... Now we have run into the situation where our
standard SQL utility is failing with the following errors. It seems the
first two messages are issued when the CONNECT RESET statement is issued
(and the second message seems to indicate that no database is connected at
all). The third message comes from our utility and is issued when it
fails to PREPARE an INSERT into the LOG4ILE table.

SQL0752 Connection cannot be changed. Reason code is 5.
SQL0900 Application process not in a connected state.
SQL0003 An SQL prepare failed; state = 08003

Analysis... To our knowledge, no DISCONNECT statement has been
issued -- at least not from any user-written code on the IBMi side. The
failure is a situation where a remote MS SQL Server process is calling one
of our stored procedures on the IBMi side. The weird thing is that the
first call works correctly -- returning the expected results to the caller
(MS SQL Server), but a second call to the same stored procedure in the
same ODBC connection fails as described above. If separate ODBC
connections are used, then all calls to this IBMi stored procedure works
correctly every time. The failure only occurs when the IBMi stored
procedure is called a second time in the same ODBC connection.

Conclusion... My only thought is that somehow MS SQL Server,
itself, is actually causing the problem in how it handles multiple
requests through the same ODBC connection -- but it is unlikely I'll get
any change in process from that end. Any other thoughts?

All of that is to also ask... In an attempt to address this (at
least for our standard SQL error utility), is there a different way that I
can assure that I am connected to the local database in our standard SQL
error utility in lieu of issuing the CONNECT RESET statement? Meaning, is
there a way of determining jsut what database I am connected to and a way
of explicitly connecting to the local database only if I need to? I know
I can connect to the local database by name, but I only want to do this if
I can determine that I am not already connected to that database. Is that
possible?

Sincerely,

Dave Clark