FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il giorno gio 21 feb 2019 alle ore 14:54 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(...)
>
> TDSDUMP shows:
>
> 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
>

I had a quick look at the Microsoft TDS document, there seems to be no
update for 2019.
Maybe they are waiting for the final release.
But is also possible that they are not changing the protocol and they
convert the column
as you seem to describe. Maybe there's a new usertype associated to the 
column.
Or maybe the server uses another way to detect if the client support
the new collations.

Frediano