× 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 06-May-2016 08:03 -0500, Ken Schwass wrote:

I am running the following command successfully.

Exec Sql
Select
SYSTOOLS.HTTPGETCLOB
(:Website, '')
INTO :vCLOB
From SYSIBM.SYSDUMMY1;

Later anytime I am using the SQLConnect API’s I get the following
error:

Connection to relational database D00D9B0R already exists.
SQLERROR. Checking Database handle...
SQLSTATE = 08002 Native Error = -842
Message = "Connection to relational database D00D9B0R already
exists.".
SQLERROR. Checking Database handle...
SQLSTATE = 08003 Native Error = -843
Message = "Connection to relational database ■■D00D9B0R does not
exist.”.


In a local connection, a resolution or preventive to problems similar to those errors msg SQL0842 and msg SQL0843, likely would come from having issued the following two consecutive SQL statements\requests:
DISCONNECT ALL
CONNECT RESET


If I don’t submit the HTTPGETCLOB my SQLConnect works fine.


I suspect the issue has something to do with a collision between the use of the SQLCLI by both the prior work and the failing work. This is something generally resolved by ensuring both features use the SQL CLI Server Mode vs local; i.e. use the SQLSetEnvAttr() API to request the CLI to operate in server-mode, thus redirecting the work to perform in a QSQSRVR server job, rather than being run locally.


Is there something I need to do after my HTTPGETCLOB command?


Although defined as a Java External [to SQL] scalar function, the system-supplied UDF HTTPGETCLOB [implemented with SYSTOOLS.DB2RESTUDF:com.ibm.db2.rest.DB2UDFWrapper.httpGetClob] does initiate some Activation Group (ACTGRP) [e.g. QJVADFTTS, QJVAJDBC, QSQCLI]. Given the code for those was written to allow restarting without errors after reclaiming the activation, thn the request to Reclaim Activation Group (RCLACTGRP) of one or more of the ACTGRPs could potentially assist. However, I have had little luck with doing so; the system-code seemed always to fail miserably when re-invoked later, because the code for the activations /assume/ some things will remain, despite the reclaim having destroyed whatever those things are. So probably better to look instead, to:

Here are three articles\documents that may assist, even if not seemingly directly equivalent\identical to the failure scenario presented by the OP:

[http://www.ibm.com/support/docview.wss?uid=nas8N1015038]
Reference #: N1015038
Java Routines Containing JDBC Not Allowed in CLI Local Mode
"... the SQLConnect API call issued by the JDBC driver fails with message SQL0842 - Connection to relational database already exists, which is an expected condition due to the CLI restriction of one connection per RDB, per job. ..."


[http://archive.midrange.com/midrange-l/200805/msg00124.html]
SQL CLI HELP! I've got 2 SQLConnect calls fighting with each other
"... if you already have one active connection, and try to create another one, the second one will fail with SQL0842. Which sounds like it matches your description of the problem [...]

The solution is to switch SQL CLI to "Server Mode". In server mode, the SQL CLI submits your SQL statements to an SQL server job instead of running them locally, and that makes it possible to have multiple connections.

There's an attribute SQL_ATTR_SERVER_MODE that you use to set this.
..."


[http://developer.developer-works.com/article/32257527/SQL0842+if+connect+then+reconnect+to+remote+database]
SQL0842 if connect then reconnect to remote database
"I have a CLI application that connects to a database, does a query, then disconnects, then some time later may need to reconnect for another query.
I don't keep the DB connection around after I'm done with it. It works fine if the database is *LOCAL, but if it's a remote database, the reconnect fails with SQL0842 (-842) ..."


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 copyright@midrange.com.

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.