Skip to Content.
Sympa Menu

freetds - Re: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol()

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Craig Jackson <cejackson51 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] SQL Server 2019: CHAR(N) using UTF-8 is seen as SQL_NVARCHAR by SQLDescribeCol()
  • Date: Wed, 27 Feb 2019 10:32:28 -0500

I don't know anything about SQL Server 2019, but if they added the option
to allow UTF-8 encoding of character strings, it would seem natural that
said strings would be variable-length, even if declared CHAR(n). Strings
encoded in UTF-8 are inherently variable length.

Craig Jackson

On Wed, Feb 27, 2019 at 10:27 AM Sebastien FLAESCH <sf AT 4js.com> wrote:

> Hi,
>
> Just tried with TDS 7.4, it did not help.
>
> I have tested the MS ODBC driver 17.3.1.1, it works as expected
> ( I get 1/SQL_CHAR from SQLDescribeCol() )
>
> You may know that it's very easy to setup an SQL Server 2019 with
> docker, do you?
>
> Cheers,
> Seb
>
> On 2/27/19 3:08 PM, Frediano Ziglio wrote:
> > Hi,
> > I would try to use TDS 7.4, not 7.3.
> > Also I would try to use Microsoft ODBC driver and a network analyzer
> > (like wireshark).
> >
> > Regards,
> > Frediano
> >
> > Il giorno mar 26 feb 2019 alle ore 11:26 Sebastien FLAESCH
> > <sf AT 4js.com> ha scritto:
> >>
> >> Testing FreeTDS 1.1rc3 with SQL Server 2019:
> >>
> >> I get an unexpected SQL type code with a CHAR(10) column, when the
> >> database collation is using UTF-8.
> >>
> >> Instead of SQL_CHAR (or SQL_WCHAR), I get SQL_WVARCHAR.
> >>
> >> I have created a database with this collation:
> >>
> >> Latin1_General_100_CI_AS_SC_UTF8
> >>
> >> Then created a table like this:
> >>
> >> CREATE TABLE mytab1 ( col1 CHAR(10) )
> >>
> >> and inserted a row:
> >>
> >> INSERT INTO mytab1 VALUES ( 'abc' )
> >>
> >> Then in the ODBC program:
> >>
> >> SQLExecDirect(.."SELECT * FROM mytab1"..)
> >> SQLDescribCol(...)
> >>
> >> Check the TDSDUMP trace in attachment (freetds-2019-1.log)
> >>
> >> token.c:1541:tds7_get_data_info:
> >> colname = col1
> >> type = 39 (varchar)
> >> server's type = 231 (x UCS-2 varchar) <-- 231 ?
> >> column_varint_size = 2
> >> column_size = 20 (20 on server)
> >>
> >>
> >> The same program, connecting to SQL Server 2017 (were DB collation is
> Latin1
> >> without UTF-8):
> >>
> >>
> >> token.c:1541:tds7_get_data_info:
> >> colname = col1
> >> type = 47 (char)
> >> server's type = 175 (xchar) <-- 175
> >> column_varint_size = 2
> >> column_size = 10 (10 on server)
> >>
> >> With SQL Server 2019, when using another collation (non-UTF-8)
> >>
> >> CREATE TABLE mytab2 ( col1 CHAR(10) COLLATE Latin1_General_CI_AS )
> >>
> >> I get the expected tds type code...
> >>
> >> Seb
> >> _______________________________________________
> >> FreeTDS mailing list
> >> FreeTDS AT lists.ibiblio.org
> >> https://lists.ibiblio.org/mailman/listinfo/freetds
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > https://lists.ibiblio.org/mailman/listinfo/freetds
> >
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> https://lists.ibiblio.org/mailman/listinfo/freetds
>




Archive powered by MHonArc 2.6.24.

Top of Page