Re: PRO*C FETCH, is this expected behavior?

fwp_at_Jester.CC.MsState.Edu (Frank Peters) writes:

>Hello,
 

>I'm in the process of learning PRO*C in ORACLE V6 running on a Sun4
>running SunOS 4.1.1. I'm having a problem which seems to indicate that
>ORACLE isn't null terminating strings after the first FETCH. The
>result is that FETCHes which yield a shorter string than the previous
>FETCH have the 'extra' characters from that previous string in the new
>string.

"Note: ORACLE does not null-terminate character strings. However, C functions such as printf() and strlen() expect the null terminator. So, it is up to your program to supply it. The VARCHAR pseudotype is useful in this regard (see the section "Declaring VARCHARs" later in this chapter)."

[From Pro*C Supplement to the ORACLE Precompilers Guide, p. 1-3]

The same is also mentioned in the same manual on pages 1-14, 1-16, 1-17, etc.

<Stuff deleted>

>And this is the relevant section of my program. Its purpose is to
>take a name and print any rows that match that name in the fname
>or lname columns.
 

>-------------------------------------------------------
>... Declarations and cp argv[1] into charmatch ...
> EXEC SQL DECLARE who_cursor CURSOR FOR
> SELECT FNAME, LNAME, CNAME
> FROM SUSERS
> WHERE UPPER(FNAME) = UPPER(:charmatch)
> OR UPPER(LNAME) = UPPER(:charmatch)
> OR UPPER(CNAME) = UPPER(:charmatch);
>
> EXEC SQL OPEN who_cursor;
> EXEC SQL WHENEVER NOT FOUND GOTO no_more;
 

> for (;;) {
> EXEC SQL FETCH who_cursor INTO :fname, :lname, :cname;
> printf("Full Name: %s %s\n", fname.arr, lname.arr);
> }
>... Program termination code ...
>-------------------------------------------------------
 

>Running this program gives the following:
 

>-------------------------------------------------------
>Full Name: Tim Griffin
>Full Name: Tim Beyeain
>-------------------------------------------------------

Actually, your program is expected to dump core. However, since Sun's compiler seems to initialize data areas with zeroes, program works and gives erraneous results.

>Notice that the second fetch ('Beyea' still has the 'in' from
>the end of 'Griffin').
 

>I can, of course, get around this by inserting the nulls myself
>or by explicitly printing variable.len characters. Before I
>get into the habit of doing one of these in all of my programs,
>though, I'd like to know if this is really the expected behavior.
>It seems like null terminating a returned output string would be
>such a simple thing. :-)

You ought to do that.

>--
>Frank Peters Internet: fwp_at_CC.MsState.Edu Bitnet: Fwp@MsState
> Phone: (601)325-7030 FAX: (601)325-8921

--
Olli Mikkonen
omikko_at_cs.joensuu.fi