Hugo Freire | 8 Oct 12:36 2015

Freetds and Unicode


I'm using Freetds from 4 years ago and works perfectly. Now we are 
trying to allow to store Unicode characters in sql server.
We have detected that we can store without problems any character from 
first plane of Basic Multilingual Plane, 
but not able to store any character from other planes.
In the Freetds documentation I can read "At some future time, FreeTDS 
aims to support Unicode and other multi-byte character sets."
After making some tests, we was able to store all Unicode characters 
using "client charset ISO-8859-1".
Unfortunately we have an heterogeneous platform with windows and linux 
systems connecting to the same data, so the data stored by Freetds using 
ISO-8859-1 can't be read by .net application for example.

Our conclusion was that FreeTDS is unable to store all Unicode 
characters in SQL Server in UCS-2.

Is it correct?
Are there any patch that allow to store all UCS-2 characters?
Is posible create a patch to allow this?
Can someone guide me to start to create this patch?

Best regards,
Jacopille, David | 5 Oct 23:07 2015

Using FreeTDS 0.95 INSERTS fail above 66000 characters...unless 'dump file' is turned on

Looking for suggestions or a troubleshooting approach on this 100%
reproducible issue where FreeTDS logging seems to be the only variable.

Since the issue goes away as soon as I turn on freetds logging I can¹t
look at the logs to find the problem.

        SQL Server 2012
        OS X 10.9.5
        FreeTDS 0.95.20
        DBD::Sybase 1.15
        TDSVER 7.0  or 7.1 (same symptoms)
        Perl 5.16.3
        FreeTDS text size = 1000000

Testing large string INSERTS to a table with a single, nvarchar(max),

A. With freetds logging on (via 'dump file = /tmp/freetds.log¹) INSERT
values from 0-500,000 characters are successful.  Decreasing reliability
above 500,000 characters.

B. INSERT statements with values of 0 thru 66,000 characters always work,
regardless of freetds logging on/off

C. SELECT work correctly for all values 0 thru one million characters,
regardless of freetds logging on/off

(Continue reading)

Sebastien FLAESCH | 22 Sep 17:07 2015

Build issue on AIX (invalid connection)

Trying to build 0.95.5 on AIX 6.1 in 64bit mode...

$ export OBJECT_MODE=64

$ CC="gcc -maix64" CXX="g++ -maix64" LDFLAGS="-maix64"  ./configure --prefix=$FTMDIR --with-odbc-nodm=/dbs/64bits/uxo/2.3.1

Note that we are using unixODBC 2.3.1, and we don't want to use unixODBC
as we link directly with libtdsodbc.a/.so  ...

A simple connection fails and SQLGetDiagRec() returns a strange error message:

   SQL State: 42000
   SQL code : 18456
   Message  : [FreeTDS][SQL Server]L

SQL SERVER error 18456 is an invalid user/login issue, but when I switch to an
older version of FreeTDS (0.92), same data source + username + login connects
without problem...

Any ideas?

I suspect some unixODBC defines problem...

Any way to check that the unixODBC defines (32b/64b SQLLEN) match?

sizeof(SQLLEN) = 8

Frediano Ziglio | 22 Sep 12:19 2015

Sybase 16 support ongoing

I fix some issues for Sybase 16. This version is able to accept LOBs
on prepared statement. There were some issues for LOBs which was not
uploaded correctly.
Looks like this server version had a lot of good improvements and optimizations.

Frediano Ziglio | 22 Sep 12:17 2015

big(date)time types added

Yesterday I finished and pushed my branch on supporting these new
types for Sybase 15.7+.

These types allow to store time or date and time with a microsecond precision.

Fabrizio Magni | 16 Sep 10:47 2015

sybase login encryption

I'm trying to connect to a Sybase obtaining this error:
Adaptive Server requires encryption of the login password on the network
I cannot change the server configuration.
Is there any way to encrypt the password?

I tried:

host =
port = 4901
tds version = 5.0
ASA database = TEST
encryption = required

But still no luck.

Worman, Tyler | 15 Sep 19:39 2015

FreeTDS build on AIX - No shared objects (.so) generated?

 Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed
online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files
from the .a that builds but it doesn't seem to work. Any advice? 

Using the following:
./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local --with-tdsver=7.0
make install

Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a
and .la files.
I tested tsql that was built. It worked and connected to my MS SQL Server instance fine. 

I then generated the .so from the .a with gcc -fpic -g -shared -o libtdsodbc.a
I verified my config using osql. It's fine until it gets to the actual connection and invoking isql
(Unixodbc 32-bit).
I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine.

The OSQL test:
./osql -S TEST -U accthere -P passwordhere

That produces this but no dump. 
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect
sed: Cannot find or open file /tmp/osql.dump.51511686.

If I do this instead, I still get no dump, and nothing is written to the file I specify.
TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U usernamhere -P passwordhere

(Continue reading)

Frediano Ziglio | 11 Sep 09:28 2015

Re: reply

2015-09-11 7:53 GMT+01:00 Frediano Ziglio <freddy77 <at>>:
> Hello everyone!
> My team and I are exploring the use of tdspool for a small project and
> we have run into a snag. The documentation on tdspool is very sparse
> and so is it’s use from what we can see.

Client libraries are used and well tested but pool and server are
really not in a good shape.

The current state of tdspool is.... it compiles! I'm not surprised it
does not run correctly.

That said it's open source. Any help/suggestion/patch is welcome.


> Starting the pool seems to go off without a hitch. Here is our pool.conf
> [global]
>         min pool conn = 5
>         max pool conn = 10
>         max member age = 120
> [sampool]
>         user = [REDACTED]
(Continue reading)

Ramiro Morales | 3 Sep 15:29 2015

Microsoft want to help django-mssql, pymssql, FreeTDS, etc.

Hi all,

Just wanted point you all to an email message (and related thread)
posted by an MS engineer to the mailing list of the Django Python Web
development framework a few days ago.

It seems there is a good chance of collaboration there for FreeTDS.
And it's good to know Microsoft is recommending to al least some of
its customers to use a stack which includes FreeTDS.



Ramiro Morales
 <at> ramiromorales
Rob Morin | 31 Aug 16:15 2015

Problem with a query against MS SQL 2005


First, please let me apologize if this already went to the group. I think 
I tried to send it before I was officially a member, so I don't know if it 
actually went or not.

I'm upgrading a server from PHP 4.3 to PHP 5.6 and doing the necessary 
code remediation.  I've got most things working, but I'm having a problem 
on certain queries and I'm to the point that I believe it is the driver 
(PHP 4.3 used a mssql driver, PHP 5.6 uses FreeTDS) that's causing the 

The Environment
CentOS 7.1 with PHP 5.6.8 and php56w-mssql from webtatic
This comes with FreeTDS 0.91 from epel

I've set the FreeTDS global protocol version to 7.2 in freetds.conf. When 
it starts, I see an error in the log : "TDS version downgraded to 7.1!" 
The wait time is also set to 180.

The log of the downgrade:
        util.c:331:tdserror(0x7fd16ec064c0, 0x7fd16ec9edd0, 100, 0)
        dblib.c:7929:dbperror(0x7fd16ec9e360, 100, 0)
        dblib.c:7981:100: "TDS version downgraded to 7.1!"
        dblib.c:8002:"TDS version downgraded to 7.1!", client returns 2 
        util.c:361:tdserror: client library returned TDS_INT_CANCEL(2)
        util.c:384:tdserror: returning TDS_INT_CANCEL(2)
        iconv.c:330:tds_iconv_open(0x7fd16ec9edd0, UTF-8)
        iconv.c:187:local name for ISO-8859-1 is ISO-8859-1
(Continue reading)

Craig A. Berry | 28 Aug 15:16 2015

[PATCH] Don't disable system's readpassphrase.h.

We were defining _READPASSPHRASE_H_ in our replacement version,
and then, when HAVE_READPASSPHRASE was defined, including the
system version of readpassphrase.h. At least on BSD-like systems,
the contents of that file are skipped when _READPASSPHRASE_H_ is
already defined.  So use our own macro to guard our own header
rather stealing the guard macro that is also used by the system.
 include/replacements/readpassphrase.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/replacements/readpassphrase.h b/include/replacements/readpassphrase.h
index db6312f..bba3190 100644
--- a/include/replacements/readpassphrase.h
+++ b/include/replacements/readpassphrase.h
 <at>  <at>  -29,8 +29,8  <at>  <at> 




Craig A. Berry
(Continue reading)