FreeTDS Development Group

["Carsten Rhod Gregersen" <crg AT rgm.dk>]

Hi Bob,

Just tell me if you want any help.

Some weeks ago I've posted a patch that makes it posible to
handle TEXT columns. My guess is the NTEXT and TEXT columns
are handled the same way.

We haven't tested the patch alot, it seems to work and we havn't had
any problems.

I send the sources to Justin Schwartz (justin AT ivorytower.co.za) who
had the same problem as I had, and therefore was requesting a
solution. Maybe he can say something about the patch.

About the unicode problem. Would it not be enough just to do
a "mystring.getBytes()" ???

/Regards
Carsten

> At the risk of making a pest of myself, I'm going to ask once again for
> a little more clarification on the state of affairs on the TDS 7.0
> support, specifically for working with NTEXT columns.  If it's
> appropriate and useful, I'd like to contribute to the efforts to
> incorporate this support into the JDBC driver.  I expect that as XML
> becomes more and more ubiquitous as a component of newly emerging
> systems and Unicode expands its role as the standard encoding for
> internationalization the support for NTEXT columns will become a core
> requirement for many projects (as it is for the project to which I'm
> currently devoting most of my time; we aren't planning to use freetds as
> part of the production project, but I would like to build some ancillary
> tools with freetds), since UTF-8 is a poor second cousin to UTF-16 for a
> number of processing tasks.
> 
> I'm guessing that the first step I would take would be to see how the C
> version of freetds does things.  Back in December, Brian wrote:
> 
> > The TDS 7.0 support is very new, so there are likely to still be
> > quirks with it. Currently the behaviour with unicode fields is to
> > strip them back down to ascii. The next step will be to allow the
> > client to specify whether it wants unicode or ascii returned when
> > binding. Running the client at 4.2 should make the ntext fields come
> > back as text fields. 
> 
> Unfortunately, I'm not able to reproduce the behavior he's describing.
> I have modified both cttest and dbtest to connect to our SQL Server 7.0
> database and select an NTEXT column from rows in one of our tables.  If
> I run with TDSVER=42 both test programs come back with the server
> message "ntext data cannot be sent to clients using DB-Library (such as
> ISQL) or ODBC version 3.7 or earlier."  If I run with TDSVER=70 then I
> get a flurry of "Unknown marker" messages folowed by "Attempting to
> convert unknown source type 99."
> 
> So, if I could be given a clue about what Brian's doing to get unicode
> stripped down to ascii, I'd be one step closer to the goal -- I'd be
> reasonably confident that we're starting from the same page.  A nice
> bonus would be some clues about what he has in mind for allowing "the
> client to specify whether it wants unicode or ascii returned when
> binding."  Without that bonus, I suppose I'll dig in and try to figure
> it out for myself.  Didn't want to duplicate effort that's already been
> expended, though.  Once I see how it's [going to be] done in the C
> libraries, it should be a relatively easy step to carry that over into
> the JDBC implementation (considerably easier, in fact, since the native
> encoding for characters in Java is a variant of UCS2).
> 
> -- 
> Bob Kline
> mailto:bkline AT rksystems.com
> http://www.rksystems.com
> 
> 
> 
> ---
> You are currently subscribed to freetds as: freetds AT rgm.dk
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>