Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Pro*C 2.0 "char" bug

Re: Pro*C 2.0 "char" bug

From: Simon Taylor <simon_at_unisolve.com.au>
Date: 1997/06/09
Message-ID: <01bc74b1$2a8c4340$026464c0@simon.iaccess.com.au>#1/1

I've seen this frightful bug before. As I recall, it occurred on some of our Unix platforms, (SCO, NCR, AIX) but not necessarily all. It was dependent on the version of Pro*c.

The only workaround that let me get any sleep at night was to permanently remove all uses of single chars in Pro*c EXEC SQL statements.

This behavior is/was also exhibited with some versions of Pro*C when calling PL/SQL procedures and functions with parameters of a single char.

-- 
Simon Taylor
Unisolve Pty Ltd         Melbourne, Australia

Rick Wiggins <rickwiggins_at_att.com> wrote in article
<33971DF8.40D9_at_att.com>...

> We've noticed an erroneous behavior with Pro*C 2.0 that doesn't seem to
> be present in versions 1.6 or 2.2. In version 2.0, if a CHAR(1)
> database column is SELECTed into a "plain old char" variable that's not
> an array (e.g. char one_char_var;), no error occurs, but the variable's
> contents ARE NOT REPLACED with what was (supposedly) pulled from the
> database! In version 1.6 and 2.2 things seem to work as expected; the
> character from the database ends up in the variable in the C program.
>
<snip>
> We usually use null-terminated "strings" (char arrays) or varchar, not
> "plain old char" or exactly-sized char arrays, but this situation scares
> me since I haven't seen it explicitly addressed and it doesn't
> necessarily cause a program to abend; it just makes it "wrong". We have
> been bitten a couple of times in Production by this and never knew
> anything funny happened until data got fouled up enough downstream to
> cause an error to occur or a person to notice.
>
> If anyone has seen and/or struggled with this and has any more
> information about this "bug", I'd love to hear about it. Incidentally,
> we're on an NCR UNIX platform, but I'm not sure whether or not this
> problem is platform-specific.
>
> Sorry this is so verbose. Thanks in advance for any feedback.
> +================+========================================+
> | Rick Wiggins | Phone: (910)279-2270 |
> | Lead Developer | FAX: (910)697-8021 |
> | AT&T HRISO | Internet: mailto:rickwiggins_at_att.com |
> | Greensboro, NC | CompuServe: rick_wiggins |
> +================+========================================+
>
Received on Mon Jun 09 1997 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US