Re: Why? Oracle LONGVARCHAR Returning Wide Chars using ODBC "default" type

In <4267071b$4$avpx$mr2ice_at_news.east.earthlink.net>, on 04/21/2005

   at 01:53 AM, "Nick Knight" <bhnc_140__at_mr2ice.com> said:

>In <42659588$1$avpx$mr2ice_at_news.east.earthlink.net>, on 04/19/2005
> at 11:36 PM, "Nick Knight" <bhnc_140__at_mr2ice.com> said:

>>I've got a couple of different versions of Oracle servers (8 & 9) running
>>in-house as test platforms. My software works very well with these via
>>ODBC connections. However, I've now hit my second install where
>>LONGVARCHAR data is coming back as wide characters - Unicode. I'm
>>expecting single byte ASCII; which is all I get from my machines.

>I hope to tame my Unicode text data tomorrow via a more brute-force
>approach. If this doesn't work, I'll beg for more ideas, but for tonight,
>I'll leave it alone.

I don't always talk to myself. Honest! But I'm not afraid to :)

Ok, the Unicode/"wide" column data being return wasn't solved via coding. In fact, everything I did, coding wise, failed. Seems I couldn't force the column to ASCII text no matter how I typed it.

I found an mildly obscure Oracle ODBC document today that explained that, if the database's character set didn't match the drivers character set, the driver "will" return Unicode strings (for some column types). Apparently this is only sometimes, as I had mixed results in my own setup.

There is a registry setting that can be changed to a non-obvious string to get the charsets to match, and no more Unicode data! Excellent. However painful it was to resolve.

>I execute many select statement meant to return multiple rows (possibly).
>These are all generated dynamically by my code. And again, all works well
>on all of my in-house servers. And it works well on this new remote
>server. Until I join in a table with a long column for that text data.

>In this case, my ODBC fetch statement (from memory, it's an SQLFetchScroll
>with ScrollNext, 1 row) returns a -1 (SQL_ERROR) and a driver error of 1403
>- no data. Uuuuh? Googling tells me that this is most commonly a read
>past end-of-results? Well, I tried to code around this by treating this
>as an "SQL_NO_DATA". Ok, so I never get ANY data, and I know there is
>some.

>Dare I say that this same code/query works on my now-local copy of the very
>same database? Without seeing the 1403 errors, which are quite new to me.

Customer's machine was running an Oracle ODBC driver of 9.0.2.0. Mine? 9.0.0.0. Bother fairly old, but how much trouble can being 0.0.2 off be? Apparently, plenty.

After spending the day trying coding tricks, and after filing a query with Oracle's metalink, I decided to download the customer's driver and see if anything acted differently. And it did.

Apparently I've flushed many hours chasing a driver bug or 2. I know the older version works well, tomorrow I'll try the latest (9.0.6.5) and HOPEFULLY it will behave better.

Thanks for listening!

Nick Received on Thu Apr 21 2005 - 18:04:28 CDT