Pratik Gandhi | 18 Jul 20:28 2016

SQL_NO_TOTAL error while using freeTDS 1.00


I am getting a SQL_NO_TOTAL error for one of the columns with data type as nvarchar(1024) when trying to move
data from MS SQL Server 2014 to MySQL 5.7. I am using freeTDS 1.00 version with MySQL Workbench on a Windows 7 machine.

Pratik Gandhi
Pratik Gandhi | 17 Jul 21:43 2016

Setting up FreeTDS to work with ODBC Data Source Administrator on Windows 7


I am currently working on a database migration project from MS SQL Server to MySQL and am using the MySQL
Workbench 6.3 for it. However, I have ran across a problem in migrating some of the data due to character
encoding issues and it has been suggested that using FreeTDS driver (instead of Microsoft's ODBC
drivers) could be of help.

Now, I have spend past couple of days reading stuff online to try and figure out how I can set up my Windows
machine with FreeTDS so that ODBC Data Source Administrator recognizes it, which is what is being used by
MySQL Workbench. I have, however, been unable to make any progress and am pretty stuck right now. I have
downloaded windows binaries from couple of places, but honestly don't know what to do with them. I have
also tried working with CMake, but again no luck there as I absolutely have no prior experience with it.

I will really appreciate if anyone can help me here and guide me through the process of making this work.


LacaK | 12 Jul 10:29 2016

Client charset in lowercase

Hi *,

now I found, that when I specify client charset as 'utf-8' and not as 
'UTF-8' I get error in log:

iconv.c:348:preparing iconv for "utf-8" <-> "UCS-2LE" conversion
iconv.c:423:tds_iconv_info_init: client charset name "-1" invalid

I am using "dblib" and I set charset using setlname()

Is it expected, documented ?


Frediano Ziglio | 10 Jul 16:42 2016

Availability Groups support in master!

Pushed last patch for this feature.

Thanks to Paul-Andre Panon for the time looking for documentation and
testing on a real setup.

Johnny Yan | 5 Jul 23:16 2016

Set up client charset with DSN-less configuration


We're writing data analytic application on Linux using FreeTDS(0.95.81) with unixODBC(2.3.4) to
connect to SQL Server databases. Since we need to programmatically decide the hosts and other info
provided by our customers, we decided to use the DSN-less configuration and pass the attributes through
the connection string. However it seems that we can't set up the client side charset correctly.

From the attached simple sample code, you could see that we could connect with that connection string(you
need to change the server and username/password if you want to test it). And we get the following head in the
freetds.log file,

log.c:167:Starting log file for FreeTDS 0.95.81
    on 2016-06-30 18:17:32 with debug flags 0x4fff.
iconv.c:328:tds_iconv_open(0xff47a0, UTF-8)
iconv.c:187:local name for ISO-8859-1 is ISO-8859-1
iconv.c:187:local name for UTF-8 is UTF-8
iconv.c:187:local name for UCS-2LE is UCS-2LE
iconv.c:187:local name for UCS-2BE is UCS-2BE
iconv.c:346:setting up conversions for client charset "UTF-8"
iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion

It seems that the client charset is set to UTF-8. Am I correct? My understanding is that this is from the LANG
env variable since we didn't specify it anywhere. Right?

However when we try to specify the charset in the connection string, that is appending
";ClientCharset=UTF-16" to the connection string in the sample, we didn't observe the expected
behavior. In another words, we still see the above bold line which implies that the ClientCharset attr in
the connection string didn't make any difference. Is that expected? Did we do it correctly? Probably not.
If so, how can we make it right?
(Continue reading)

Harris, Sean | 4 Jul 23:43 2016

FOR XML, TYPE seems broken with latest 1.0x

Hey guys,

So I updated a mac dev machine to the latest release available via home brew (1.00.9).

After this any queries using the TYPE directive for XML return an unknown type error.

example query: SELECT * FROM users WHERE id = 123 FOR XML PATH('users'), ROOT('xmlObject'), TYPE

About the TYPE directive:
Stuart Henderson | 28 Jun 23:19 2016

sqsh build fails with FreeTDS 1.0

sqsh build is failing with newer FreeTDS. There's an easily fixed
CS_TDS_80 that can be replaced with CS_TDS_71, but when that's done
I run into this in src/dsp_conv.c:

     * Take the existing format and strip it down according to the
     * type of date that we are processing and replace the ms
     * field if it exists.
#if defined(CS_BIGDATETIME_TYPE) && defined(CS_BIGTIME_TYPE)
    if (dt_fmt->datatype == CS_BIGDATETIME_TYPE || dt_fmt->datatype == CS_BIGTIME_TYPE)
        fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datesecfrac );
        fmt = dsp_datetime_strip( dt_fmt->datatype, conv_fmt, (int) dr.datemsecond );

- CS_BIGDATETIME_TYPE etc are now defined, but the structure
doesn't include datesecfrac:

dsp_conv.c: In function 'dsp_datetime_conv':
dsp_conv.c:665: error: 'CS_DATEREC' has no member named 'datesecfrac'

Any suggestions for a better fix than just #if 0'ing it out?
John Kendall | 22 Jun 17:01 2016

Re: bcp -n -E fails on identity column

My last attempt to report this was a bit muddled.  Here's another try.  
Using version 1.00.6.

Using the bcp -n (native file format) and -E (retain identity values) options together produces:

   Msg 20060, Level 11
   Unknown datatype encountered

   Error in bcp_colfmt col 1

I see this happening on Sybase (11 & 16) and MS SQL 2008.  

Test to reproduce:

   select id_col=identity(5) into tempdb..tbl   -- Sybase
   select id_col=identity(int) into tempdb..tbl  -- MS SQL

   $ freebcp tempdb..tbl out tbl.bcp -S $DSQUERY -U usr -P pw -n -E
   Msg 20060, Level 11
   Unknown datatype encountered

   Error in bcp_colfmt col 1

datacopy also has a problem with the -E option, I assume the problems are related.

Fabrice Manfroi | 22 Jun 16:12 2016

Build error on AIX 6/7 with freeTDS 1.00.6 (current stable)


I'm trying to build the last stable freeTDS sources but it fails with
the following compilation errors:

tls.c:719: error: 'AF_INET6' undeclared (first use in this function)
tls.c:719: error: (Each undeclared identifier is reported only once
tls.c:719: error: for each function it appears in.)
tls.c:722: error: 'AF_INET' undeclared (first use in this function)

It seems that an include of the sys/socket.h header is missing.

I propose the attached patch to fix the problem.

Best Regards.

FreeTDS mailing list
FreeTDS <at>
Adam Baratz | 21 Jun 23:45 2016

version detection

Following up on my pdo_dblib thread, I'd like to be able to detect which
version of FreeTDS is installed. So I can know when the dbnextrow()
workaround should be used instead of dbcanquery(). As far as I can tell,
the version only gets exposed through dbversion(), which is a string I'd
have to parse.

Nem W Schlecht | 16 Jun 22:20 2016

Another defncopy patch - check dbopen results

I have another defncopy patch to fix another issue.  The results from
dbopen() are just checked with an assert() call.  Thus, if I type in
the wrong database name, username, whatever, I get a core dump that I
have to clean up from a typo on my part.  What do you all think of a
quick check/message/exit, similar to what happens with tsql?

Patch attached.  Just checks to see if dbproc has a value.  If not,
prints an error message and exit(1)s.  Otherwise, continues on.

I deal with a lot of servers and a lot of usernames/passwords, so this
one hits me fairly often.


Nem W Schlecht
 "Perl did the magic.  I just waved the wand."
Attachment (defncopyfix-20160616.patch): application/octet-stream, 721 bytes
FreeTDS mailing list
FreeTDS <at>