Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.misc -> Re: Why? Oracle LONGVARCHAR Returning Wide Chars using ODBC "default" type

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

From: Nick Knight <>
Date: Thu, 21 Apr 2005 01:53:16 GMT
Message-ID: <4267071b$4$avpx$>

In <42659588$1$avpx$>, on 04/19/2005

   at 11:36 PM, "Nick Knight" <> 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 forgot until I checked today, but I also have tested on an Oracle 10 server in-house.

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.

HOWEVER, I have a few other weird things happening, only on this remote install, that I'd like to get some feedback on, please.

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.

Any ideas?

Thanks again, in advance, for any and all replies,

Nick Received on Wed Apr 20 2005 - 20:53:16 CDT

Original text of this message