Re: OCI and V7

In article <40!lq#_.tssmith_at_netcom.com>, tssmith_at_netcom.com (Tim Smith) writes:
|> In article <4118_at_unixhub.SLAC.Stanford.EDU> ian_at_jupiter.SLAC.Stanford.EDU (Ian A. MacGregor) writes:
|> >In article <1992Jun4.010823.22604_at_cognos.com>, nigelc_at_cognos.com (Nigel Campbell) writes:
|> >|> Simple question:
|> >|>
|> >|> Are there any migration issues for a system using OCI with
|> >|> V6 vs V7 ?
|> >|>
|> >
|> >There are a few. I'm not sure if they are associated with V7 or new version
|> >of OCI. The first is that a null value not handled through an indicator
|> >variable will cause the program to fail. I am not sure if this happens an
|> >run or compile time.
|>
|> This is a general change in behavior, for both the OCIs and the precompilers.
|> It's a runtime error.
|>
|> >This to me is a good change. Improperly handled null values currently
|> >result in incorrect output.
|> > V7 has different
|> >datatypes. The old char is now varchar2 and can hold up to 2000 bytes.
|> > Char is similar except entries are stored blank padded.
|> > I am not sure what impact this
|> >has on OCI. Lastly there has been some talk of no longer supporting the "old"
|> >OCI call syntax.
|> >
|> > Ian MacGregor
|> > Stanford Linear Accelerator Center
|> > (415) 926-3528
|>
|> CHAR is fully ANSI compatible, with a maximum length of 255. CHARs are not
|> really stored blank-padded (that would be greatly inefficient), but they
|> observe blank-padding semantics on input and output.

I checked my manuals and indeed char variable types have a maximum length of 255 characters while varchar2 has a maximum of 2000 characters. However, the description of the char variable type in the SQL LANGUAGE REFERENCE MANUAL VERSION 7.0 page 3-22 states

"The CHAR datatype specifies a fixed lenght character string. When you create a table with a CHAR column, you can supply the column length in bytes. Oracle subsequently ensures that all values stored in that column have the this length. If you insert a column which is shorter than the column length, ORACLE BLANK-PADS the value to [the] column length." This suggests that things are stored blank-padded.
|>
|> Don't know what you mean by not supporting the "old" OCI call syntax. The
|> only things that have changed are that a few old HLI routines are no longer
|> in the library. (The ones that people were warned about in the V6 manual.)
|>
That is exactly what I meant.

|> There are 5 new routines that support new V7 features, including OFLNG that
|> allows you to fetch portions of a (2GB) LONG column.
|>
|> The V7 OCIs are fully backward compatible with V6. You can choose linktime
|> options to preserve V6 compatibility, or you can recode (slightly), and
|> get the advantages of V7 (especially greatly reduced network traffic).
|>

Are there any reasons besides supporting "upiall" which result in reduced network traffic?
|> --Tim (tssmith_at_netcom.com) or (tssmith_at_oracle.com)

                Ian MacGregor
                Stanford Linear Accelerator Center
                 (415) 926-3528