FreeTDS Development Group

["Sam Sam" <s4m AT mailcity.com>]

--

On Fri, 2 Jun 2000 07:50:36   
 camber wrote:
>
>This is the default text size, just do a 'set textsize <value>' to
>increase it.  

where do i have to write this ? on my php code ? or ??
please explain more further...

thank's
sam


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct

From bkline AT rksystems.com Sat Jun 03 16:15:39 2000
Return-Path: <bkline AT rksystems.com>
Received: from rksystems.com ([209.50.228.97]) by franklin.oit.unc.edu with 
SMTP (Lyris Server version 3.0); Sat, 03 Jun 2000 16:15:35 -0400
Received: from localhost (bkline@localhost)
        by rksystems.com (8.9.3/8.9.3) with ESMTP id QAA24615
        for <freetds AT franklin.oit.unc.edu>; Sat, 3 Jun 2000 16:27:16 -0400
Date: Sat, 3 Jun 2000 16:27:16 -0400 (EDT)
From: Bob Kline <bkline AT rksystems.com>
To: TDS Development Group <freetds AT franklin.oit.unc.edu>
Subject: NTEXT support (again)
Message-ID: <Pine.LNX.4.10.10006031106001.24502-100000 AT rksystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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