Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VARCHAR2 in Pro*C

333 views
Skip to first unread message

Thomas Booker

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

I am using Pro*C to select a group of rows from Oracle. One of the
columns is a VARCHAR2, with data varying in length from 1 character
to 550 characters. When I select the column in OCI, the program returns
only
the text of the string in the column, no extra spaces. When I select
the column
in Pro*C, it pads the column out to 550 spaces, regardless of how long
the
actual string is.

Is there an easy way around this? I tried RTRIM() to get rid of the
padded
spaces, but that didn't help. I only want the text in the column, not
extra
spaces at the end.

Any help would be appreciated.

Thanks in advance.

- Tom Booker (book...@mchip00.med.nyu.edu)

Allen Kirby

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to book...@mchip00.med.nyu.edu

Make sure you declared the oracle variable as a varchar2 and not a
char or char *. The data is put into the .arr structure member and
the length is in the .len member. This should work just fine.

--
---
Allen Kirby AT&T ITS Production Services
aki...@att.com Alpharetta, GA.

Lance Humpert

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to


Thomas Booker <book...@mchip00.med.nyu.edu> wrote:

> When I select the column in Pro*C, it pads the column out to
> 550 spaces, regardless of how long the actual string is.
>
> Is there an easy way around this?

It sounds to me as if you are declaring the host variables in your
sql area as 'char' datatypes instead of using Oracle's 'varchar'
datatype.

The 'char' datatype will always be blank-padded by Oracle, whereas
the 'varchar' datatype will be varying length. The catch is, however,
that varchars are not null terminated. Instead, oracle provides a
length byte as part of the varchar data structure so that you know
the length of the field that was fetched.

You see, varchars get expanded by the pro*c precompiler into little
structs that contain a length byte and a charater array. These
components are can be referenced in your pro*c source code by adding
a suffix of either '.len' for the length byte or '.arr' for the
character array to your field name.

If you are already using varchars in your sql area, then I have no
idea what I'm talking about! If not, and if you convert to varchars
and still have problems, welcome to the club.

FYI, I don't use the length byte, opting instead to fill each
character array with null values prior to fetching from oracle. That
way, my varchars are null terminated (as long as they're one byte
longer that the longest value fetched).

Good luck,
Lance Humpert
Client Server Programmer/Analyst
Thomas Jefferson University
Philadelphia, Pa.

Schöpflin

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

There is a real C string data type in Pro/C (type id 5). It's zero
terminated and everything, you might want to try this one.
--
Markus Schoepflin www: http://www.ginit.de
GINIT Gesellschaft fuer integrierte email: schoe...@ginit.de
Informationssysteme mbH phone: +49 721 9 66 81 67
Vincenz-Priessnitz-Str. 1 fax: +49 721 9 66 81 11
D-76131 Karlsruhe, Germany


george

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

"Schöpflin" <schoe...@ginit.de> wrote:

Here is more about string: The next three lines define a
null-terminated string known to both Oracle and C. I've found this
to be very helpful: I never have to worry about the null termination
of the string if I use this and I'm not sure, but I don't think the
data is padded with blanks.


typedef char CHAR31[31];
EXEC SQL TYPE CHAR31 IS STRING(31);

CHAR31 mystring;

Note, the last character is used for the null. This variable can
therefore handle CHAR types of up to 30 characters in length.
If you try to select something with more than 30 into mystring,
Oracle will give you a 'truncation' error.

George

to select


Thomas Booker

unread,
Apr 26, 1997, 3:00:00 AM4/26/97
to

Thanks for all of your suggestions and help. The STRING
solution that Markus and George talked about was exactly what
I needed.

Once again, thanks a lot...

- Tom Booker (book...@mchip00.med.nyu.edu)

0 new messages