IDS Forum

Re: Unfamiliar SQLCODE values using JDBC with Info

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

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

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

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.