Re: Oracle ODBC / UNICODE Non Conformance

In article <8s0ols$d7u$1_at_nnrp1.deja.com>,   David Murphy <davidmurphy7799_at_my-deja.com> wrote:
>
> Lets go again for simplicity and pretend there is no NCHAR since its
> not clear to me what its for. In addition you are saying
> that regular old CHAR can store double byte UNICODE which is nice.
 That
> means we dont have the duality of MS SQL Server which has CHAR for
> single byte and NCHAR for double byte..So we also dont need to wait
 for
> Oracle 9..

Ignoring NCHAR will be appreciated-- makes it less likely I say something stupid.

Having CHAR columns that are able to store either Unicode or ANSI data is nice in certain respects, not so nice in others.

> On point 4 this is the SQL column type, not the C type. So the choices
> are SQL_CHAR or SQL_UNICODE_CHAR not SQL_C_CHAR or SQL_C_WCHAR.
> I assume from the other info you have provided that SQL_CHAR should be
> fine to bind UNICODE data.

Yes, I meant SQL_CHAR where I said SQL_C_CHAR and SQL_UNICODE_CHAR where I said SQL_W_CHAR.

If you want the data to be passed around as UNICODE, you should bind it as SQL_UNICODE_CHAR.

> To be quite honest I dont know why the application has to provide this
> value on a SQLBindParam - surely the db knows the column type better
> than the application..

Not necessarily. If I have a CHAR parameter, there's no way for the ODBC driver to know whether the parameter should be treated as UNICODE or ANSI. Only the application knows for sure.

> On the same subject is the very problematic Column Size argument to
> SQLBindParam whose description in the ODBC pages is totally ambiguous
> and whose
> implementation seems to vary from driver to driver and database to
> database. ?
> Microsofts ODBC drivers for Access and SQL Server behave totally
> differently in respect to this problematic parameter. Once you start
> talking about binding
> INOUT paramters (EG Stored Procs) with SQLBindParam its usage is a
> nightmare.
>
> Is there a coherent description of Oracle's use of this parameter?

At least in Oracle, this parameter should be the length of the data in bytes (in keeping with the strlen_or_indp argument). I agree that the spec is, well, less than crystal clear on this point.

Justin Cave
Oracle ODBC Development

Opinions expressed herein are my own and may not reflect those of Oracle Corporation.

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Oct 11 2000 - 00:10:18 CDT