John Kendall | 6 Feb 10:33 2016

compute rows

I am having trouble with the output of compute rows.  I found the following exchange from 2007 between jkl and
Michael Peppler that summarizes what I'm experiencing in 2016:

To summarize, sqsh (and other tools linked to freetds) do not produce usable output for compute rows. 
Michael Peppler says that sqsh acts correctly when linked to sybase libs.  I have an old copy of isql that
handles compute statements in a very predictable way, for example:

select col1=1, col2=1, col3=1 into
insert select 2,2,2
insert select 3,3,3
select * from compute sum(col1), avg(col1), min(col1), count(col1), avg(col2),
max(col3), min(col3)
 col1        col2        col3        
 ----------- ----------- ----------- 
           1           1           1 
           2           2           2 
           3           3           3 
 avg         avg                     
 =========== ===========             
           2           2             
 min                     min         
 ===========             =========== 
           1                       1 
(Continue reading)


php mssql_connect() without section name in freetds.conf


anybody have any idea with the following ?

Does not work, gives 'Unknown host machine name'. Even with tds version = 7.0... 7.1, 8, etc..:

$link = mssql_connect("", 'user', 'pass');

Works because there is a section in freetds.conf named 'dasdswh':

$link = mssql_connect('dasdswh', 'user', 'pass');

$ php -v
PHP 5.5.21 (cli) (built: Jun 10 2015 05:26:44)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

Trace log:

16:55:35.585240 15567 (log.c:196):Starting log file for FreeTDS 0.91
        on 2016-02-04 16:55:35 with debug flags 0xffff.
16:55:35.585295 15567 (iconv.c:330):tds_iconv_open(0x2569f10, UTF-8)
16:55:35.585508 15567 (iconv.c:187):local name for ISO-8859-1 is ISO-8859-1
16:55:35.585528 15567 (iconv.c:187):local name for UTF-8 is UTF-8
16:55:35.585542 15567 (iconv.c:187):local name for UCS-2LE is UCS-2LE
16:55:35.585560 15567 (iconv.c:187):local name for UCS-2BE is UCS-2BE
16:55:35.585578 15567 (iconv.c:349):setting up conversions for client charset "UTF-8"
16:55:35.585590 15567 (iconv.c:351):preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
16:55:35.585610 15567 (iconv.c:391):preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
(Continue reading)

Andrew Punch | 3 Feb 05:40 2016

freebcp adding escaping


I had a requirement to have properly formatted CSV output from freebcp. 
Unfortunately freebcp (and the original bcp) do not escape characters 
correctly. For example in a comma delimited file commas will not be 
escaped. Also the way NULLs are indicated can be inconvenient.

I hacked together a patch which I have attached. I would like to do a 
pull after a clean up but I have a few questions:

 1. is dblib the best place to make the change?
 2. what is the best structure to pass parameters and flags? Namely:
     1. Flag for delimiter escaping
     2. The actual delimiter (I notice that the column delimiter changes
        to EOL for the last column)
     3. Flag for NULL string replacement (instead of ASCII NUL)
     4. NULL string replacement

Attachment (smart.patch): text/x-patch, 4452 bytes
FreeTDS mailing list
FreeTDS <at>
Thompson, William | 2 Feb 15:20 2016

Problem with src/tds/write.c

Hi All,

I'm investigating an issue which is affecting some of my processes which use the db-library bcp API.
I'm getting an error back from SQL Server: "The incoming tabular data stream (TDS) protocol stream is
incorrect. The stream ended unexpectedly."
After debugging it, It turns out we have an edge case involving some of the functions in src/tds/write.c

The functions tds_put_int8, tds_put_int and tds_put_smallint do not check that there is sufficient
space in the packet buffer for their respective data types.
As a consequence, data gets dropped if it happens that one of these data types is being added to the packet
buffer when the packet size is reached.

Having looked at the functions, I think I'm going to change these lines (which occur in all the functions):

        if (tds->out_pos >= tds->out_buf_max)
                tds_write_packet(tds, 0x0);

to be:

        if (tds->out_pos  + sizeof(TDS_INT) >= tds->out_buf_max)   /* or TDS_INT8 or TDS_SMALLINT */
                tds_write_packet(tds, 0x0);

If I do this there will be cases where the packet (although not a final packet) is smaller than the maximum size,
but I REALLY don't want to go anywhere near those TDS_PUT_UA* macros. :)
Incidentally, what is the idea behind this TDS_ADDITIONAL_SPACE macro and all those TDS_PUT macros? Life
used to be much simpler (sigh), e.g.

<old code>
Int tds_put_smallint(TDSSOCKET * tds, TDS_SMALLINT si)
(Continue reading)

Thomas, Christopher (LLU | 29 Jan 21:54 2016

Weird tsql behaviour


I got a report from one of the developers that PHP couldn't connect to one of our databases. This happens
every once in a while and I always try to connect using tsql first to see if it is a PHP problem or a problem much
lower in the stack. Once I connected to the database server using tsql, the line numbers started to go up and
up, automatically. About one digit per second. I've never seen this before, but I bet whatever is causing
this is also making PHP not be able to connect to the database. I can't figure out what is going on. Does
anyone have any suggestions? The db server is MS SQL Server 2008 R2 with SP2. The application server is RHEL
7 using the FreeTDS that comes from EPEL, 0.95.19.

Christopher Thomas - Associate Director, Administrative Systems
LOMA LINDA UNIVERSITY | Information Services

11172 Anderson Street, Loma Linda, California 92350
(909) 558-7866
LLU Information Systems:
Zoom Room:

CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and
privileged information for the use of the designated recipients named above. If you are not the intended
recipient, you are hereby notified that you have received this communication in error and that any
review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you
have received this communication in error, please notify me immediately by replying to this message and
destroy all copies of this communication and any attachments. Thank you.
jezekj | 28 Jan 20:51 2016

Invalid Cursor state

first of all I would like to thank you for creating and maintaining FreeTDS. In our application we do have
procedure to trace progress of huge procedures execution to easily find out where the error is. This
procedure contains raiserror function. When in another procedure I call select after trace procedure is
called out I got invalid cursor state. i.e.:
create procedure sp_trace as
  raiserror('test', 0, 1)
create procedure sp_test_me as
  select getdate()
  execute sp_trace
  select getdate()
Then we call out from perl:
my $dbh=APPDBI->masterConnect();
my $statement='execute sp_test_me';
my $sth=$dbh->prepare($statement);
my $sth->execute;
while (my $d=$sth->fetch;){ #get 1st result set (first getdate)
  print Dumper $d;
while (my $d=$sth->fetch;){ #get 2nd result set (second getdate)
  print Dumper $d;
(Continue reading)

Ken Collins | 26 Jan 03:08 2016

FTP Down

I noticed the FTP site is down. Been having issues building FreeTDS on my CI boxes for the past few days.
Started on Saturday I think.

 - Ken
FreeTDS mailing list
FreeTDS <at>
Russ Sivak | 25 Jan 21:52 2016

FreeTDS slow with SQL Server 2014

We have been using SQL Server 2008 and things have been good. 

Recently we have upgraded to SQL Server 2014 and things have become VERY
slow.  We are using FreeTDS freetds-0.91-2.el6.x86_64, which is the
latest from EPEL that for CentOS 6.

This communication (including any attachments) is intended solely for the
recipient(s) named above and may contain information that is confidential,
privileged or legally protected. Any unauthorized use or dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please immediately notify the sender by return e-mail message and delete
all copies of the original communication. Thank you for your cooperation.
Joshua Lang | 16 Jan 02:41 2016

Empty VARCHAR parameters converted to NULL

In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc VARCHAR
parameters of 0 length, but non-NULL (empty strings). FreeTDS seems to turn
these into NULL values before passing them on to SQL Server. From what I've
read, it seems as if older databases didn't support passing empty strings,
but newer ones do? (i.e. TDS 7.0+ do support empty strings).

It seems as this is a known issue, but I was wondering if it is possible to
fix it for the newer versions of SQL server? E.g. in dbrpcparam() passing a
non-NULL pointer to the 'value' parameter and a 0 to 'datalen' would
indicate an empty string is desired if possible.

Frediano Ziglio | 12 Jan 12:48 2016

Re: Can connect with tsql but not with isql

> From: Bilal Hasan <mithrazor <at>>
> To: freetds <at>
> Cc:
> Date: Mon, 11 Jan 2016 08:13:51 -0600
> Subject: Can connect with tsql but not with isql
> I'm having an issue where I can connect to tsql but not through isql and DBD:ODBC which is my end goal. With
DBD:ODBC it doesn't complain about not being able to connect. But I don't receive any data.
>  I connect to tsql using:
> tsql -S MyDB-U MyUser
> But when I try to connect specifying the password in the command
> ie: tsql -S MyDB -U MyUser -P MyPass

That's weird. Are you sure you don't need to quote your password as
containing strange characters?

> It gives me the following error:
> locale is "en_US.UTF-8"
> locale charset is "UTF-8"
> using default charset "UTF-8"
> Msg 18456 (severity 14, state 1) from ELEONIE-VM4\SCMSERVER Line 1:
> "Login failed for user 'MyUser'."
> Error 20002 (severity 9):
> Adaptive Server connection failed
> There was a problem connecting to the server
(Continue reading) | 7 Jan 10:31 2016

SQL Cluster always on

Hello everyone,

We would like to adapt freetds to SQL Server Always On Clustering.

This kind of cluster is pretty simple: 

        Every database has associated a Listener with a dns name. E.g.

        Every listener has 2 or more IPs associated:
        nslookup responds something like:

        Only one of the IP's serves the database (active-passive)

        The connection has to be made directly to the listener. and use
the IP that is working at that moment.

TDS Behaviour at this point.

    Right now, TDS works as long as the listener is in the first node.
In the example
          instance working in

    If the database is moved to another instance, it returns a timeout.
Never checks the rest of IPs

Possible solution

        Try to login in several times with as many objects as IP's are
(Continue reading)