Skip to Content.
Sympa Menu

freetds - Re: [freetds] dbcoltype() , char and nchar

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] dbcoltype() , char and nchar
  • Date: Mon, 20 Sep 2010 22:09:26 -0400

LacaK wrote:
>
> Only for explanation:
> In FreePascal there are different Database Field Types
> TStringField and TWideStringField, so my attempt was map
> char, varchar to TStringField
> nchar, nvarchar to TWideStringField (see
> http://docwiki.embarcadero.com/VCL/en/DB.TWideStringField )
> (text to TMemoField, ntext to TWideMemoField)

I understand what you want to do. Unfortunately it will be quite
difficult with db-lib, because FreeTDS intentionally conceals the server
column definition. It was a design decision -- maybe not the right one!
-- but it's very deep in the library.

As soon as UCS-2 data arrive from the server, they are immediately
converted to the client's encoding. The UCS-2 form is discarded.[1] To
provide UCS-2 data to FreePascall, you'll have to re-convert!

Getting db-lib to report the server's type and size wouldn't be
particularly hard. The TDSCOLUMN structure has a nested on_server
structure with exactly that information. That structure could be
harmlessly added to the DBCOL structure filled by dbcolinfo(). I think if
you look at dbcolinfo() and dbcoltype(), you'll see what to do. Look at
tds_set_column_type() too.

HTH.

--jkl

[1] This was my design many years ago, and I now think it was the wrong
choice. Converting to the client's charset is a matter of *binding*, and
binding should be handled as late as possible. dbbind() is where the
conversion should happen, and dbdata() should return the original UCS-2
data as delivered by the server.




Archive powered by MHonArc 2.6.24.

Top of Page