IDS Forum

Re: Unfamiliar SQLCODE values using JDBC with ....

Posted By: Fernando Nunes
Date: Sunday, 15 February 2015, at 6:17 p.m.

In Response To: RE: Unfamiliar SQLCODE values using JDBC with .... (Mitchell, Jeffrey J.)

Yes...

On Sun, Feb 15, 2015 at 11:10 PM, Mitchell, Jeffrey J. <JJMitchell@west.com>
wrote:

> The confusing thing about this is that the procedure never really
> executes. We
> have "logging" in the procedures - start/stop times, parameters passed in,
> return string, etc. Other types of errors are showing up in the logging
> tables, but these three errors do not show up in the logging tables. We
> think
> it's coming from jdbc on the client side, but their logging isn't real
> detailed. Without more detailed logging (not easy to do), it's a bit
> difficult
> to pinpoint what's causing the problem.
>

Perfectly possible... The locale error may happen when converting data
beforesending it to the engine, although when I saw it it was the opposite
(data coming from the server)

The socket error naturally comes from the client... the query cannot be
sent to the engine, because the communication channel was closed. It's an
appserver error that causes the client error.

The last one also seems plausible... if the parameter name is wrong, the
prepare will fail.

Bottom line is, further investigation is required on the code and data,
with the exception of 79716. This is the simplest one. Change your firewall
rules or activate keepalive in the Informix engine and set the OS
parameters so that the keepalive probes are sent before the firewall
considers the connection as "stale"

Regards

>
> Jeff Mitchell
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Fernando
> Nunes
> Sent: Sunday, February 15, 2015 5:06 PM
> To: ids@iiug.org
> Subject: Re: Unfamiliar SQLCODE values using JDBC with .... [34677]
>
> The errors are not necessarily strange...:
> finderr -23103
> -23103 Code-set conversion function failed due to an illegal sequence or
> invalid value.
>
> Illegal or invalid characters occur in the character string. The program
> could
> not execute the code-set conversion on the characters that this string
> contains. Reexamine the input string for illegal or invalid characters and
> reexecute the program.
>
> A common cause for this is the existence of characters inside the database
> which are not acceptable in the database codeset. You'd need to identify
> the
> table and try to unload it using DB_LOCALE != CLIENT_LOCALE. This will make
> the client try the conversion and in that case, if there's an invalid
> character you'll see the error. The reason for that to happen is a mix of
> factors: Informix bugs, bad planning and usually mixing windows characters
> with 8859-1 codeset
>
> finderr -79716
> -79716 System or internal error.
>
> An operating or runtime system error or a driver internal error occurred.
>
> The accompanying message describes the problem.
>
> One of my "favorites". Mostly seen with J2EE application servers, and a
> firewall between the server and the application server. When the
> connections
> stay idle for too long, the firewall sees no traffic and decides to close
> the
> connection. Problem is, and don't ask me why, the sockets endpoints (at
> least
> on the app server side) never notice that. And when the application asks
> for a
> connection (getConnection()) the application server provides one for which
> the
> socket reference at the OS level is not open anymore. There are two
> solutions
> for that:
> 1- Fix the firewall rules and/or the way it kills the connections
> 2- Activate the TCP keepalive. From the Informix perspective it usually is
> enough to add "k=1" in the options field of the $INFORMIXSQLHOSTS used by
> the
> listener. But then you need to alter the OS TCP keepalive parameters.
> The defaults are usually 2H which is useless in most cases as people tend
> to
> trigger the firewall rules at 1H or so.
> I plan to write an blog post on this soon...
>
> finderr -79887
> -79887 Parameter name not found.
>
> A parameter name is not found in the argument names of the specified stored
> procedure. Either one of the parameter names is not valid or the stored
> procedure name is incorrect.
>
> Correct the parameter or procedure name and run the procedure again.
>
> This one suggests something doesn't match between the procedure definition
> and
> the calling code. Is that possible?
>
> Regards
>
> On Fri, Feb 13, 2015 at 8:39 PM, Mitchell, Jeffrey J. <JJMitchell@west.com
> >
> wrote:
>
> > We've got an application using JDBC to make stored procedure calls
> > against Informix 11.70 - and one of the arguments is a collection.
> >
> > The application logs are showing the following sql errors, but some of
> > them are unfamiliar to us.
> >
> > -23103
> > -79716
> > -79887
> >
> > We have some custom tracing in the stored procedures that store
> > information into a log table, and we can see other sqlcode in there -
> > such as -271, -268, etc. - and these make sense. We do not see entries
> > in the log tables for the above three sqlcodes.
> >
> > Does anyone have any useful hints on the above sqlcodes? I've looked
> > them up, but the descriptions are a bit vague (and we - our dba group
> > - is not all that familiar with the application code.
> >
> > Thanks,
> >
> > [Description: image001]Jeffrey J. Mitchell Database Administrator -
> > Interactive Services
> > 402-716-0500 | Cell 402-321-7443 |
> > jjmitchell@west.com<mailto:jjmitchell@west.com>
> > West Corporation, 11650 Miracle Hills Drive, Omaha NE 68154
> >
> > This electronic message transmission, including any attachments,
> > contains information from West Corporation which may be confidential or
> privileged.
> > The
> > information is intended to be for the use of the individual or entity
> > named above. If you are not the intended recipient, be aware that any
> > disclosure, copying, distribution or use of the contents of this
> > information is prohibited.
> >
> > If you have received this electronic transmission in error, please
> > notify the sender immediately by a "reply to sender only" message and
> > destroy all electronic and hard copies of the communication, including
> > attachments.
> >
> >
> >
> >
>
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --001a1138ea24de943e050f2880b0
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...

--001a1138ea24240d9b050f28ad4f

Messages In This Thread

• Unfamiliar SQLCODE values using JDBC with Informix
  Mitchell, Jeffrey J. -- Friday, 13 February 2015, at 3:39 p.m.
  • Re: Unfamiliar SQLCODE values using JDBC with Info
    Art Kagel -- Friday, 13 February 2015, at 4:22 p.m.
    • RE: Unfamiliar SQLCODE values using JDBC with ....
      Mitchell, Jeffrey J. -- Friday, 13 February 2015, at 5:19 p.m.
  • Re: Unfamiliar SQLCODE values using JDBC with Info
    Fernando Nunes -- Sunday, 15 February 2015, at 6:05 p.m.
    • RE: Unfamiliar SQLCODE values using JDBC with ....
      Mitchell, Jeffrey J. -- Sunday, 15 February 2015, at 6:10 p.m.
      • Re: Unfamiliar SQLCODE values using JDBC with ....
        Fernando Nunes -- Sunday, 15 February 2015, at 6:17 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.