Frediano Ziglio | 22 Feb 13:43 2015
Picon

Removing old memory debugging code

Hi,
  I noted that there are some residual attempt to use some memory
debugging all around. One is the manual "crumbs" in dblib tests and
the other is a lot of includes for dmalloc headers. They are quite
confusing, not used since a while and probably not that updated
(valgrind is used instead which is much easier and does not require
source changes).

If nobody complain I will remove both from sources.

Frediano
Frediano Ziglio | 15 Feb 11:16 2015
Picon

Starting preparing a new release

Hi,
  I finally found some time to start preparing a new release. This
morning I went throw my todo list and marked mails trying to prepare a
todo list for the release.

Still in early stage but I posted on
https://trello.com/b/bk0UZNRJ/freetds-todo-list (well, it's all open
stuff :) ). I don't know much about Trello so if you need write access
just ask it.

This time I'm really alone in this so please any help is really
appreciated. FreeTDS has a lot of documentations to update and there
has been quite a lot of changes from 0.91 (there are more or less 850
patches from the fork).

Frediano
LacaK | 6 Feb 14:30 2015
Picon

Attempt to initiate a new Adaptive Server operation with results pending

Hi,
I have program which uses FreeTDS db-lib.dll
Now I have changed TDS version from 7.1 to 7.3 and I start receiving 
"Attempt to initiate a new Adaptive Server operation with results 
pending" in some places.

For example, when I send this two commands:
"IF  <at>  <at> TRANCOUNT>0 ROLLBACK"
followed by:
"BEGIN TRANSACTION"
I get above mentioned error.

I attach portion of logs for 7.1 and 7.3 version.

As you can see in both cases is returned : more_results = 1 after "IF 
 <at>  <at> TRANCOUNT>0 ROLLBACK"
(I do not understand why?)
But in case 7.3 is error raised afterward (in 7.1 no error)

Is it expected ? Can you give me some explanation what is going on ?

Thanks
-Laco.
dblib.c:1673:dbresults returning 2 (NO_MORE_RESULTS)
dblib.c:1333:dbcmd(04D59AB8, IF  <at>  <at> TRANCOUNT>0 ROLLBACK)
dblib.c:1339:dbcmd() bufsz = 17
dblib.c:5833:dbfreebuf(04D59AB8)
dblib.c:1387:dbsqlexec(04D59AB8)
(Continue reading)

Frediano Ziglio | 5 Feb 21:33 2015
Picon

Snapshot is now working !!

Hi,
  a couple of days ago I fixed the snapshot generation. In particular
userguide and reference are now generated. Also freetds-current* files
point to the right versions so from the website you can just download
the "Current Snapshot" (http://www.freetds.org/software.html).

I'm now trying to collect things to do before a possible release.

Regards,
   Frediano
Geoff Montee | 3 Feb 22:33 2015
Picon

Problems on CentOS 7 connecting to MS SQL Server with ODBC and SQLDriverConnect

There's quite a bit of background to this problem that can be found here:

https://mariadb.atlassian.net/browse/MDEV-7508

But to keep the problem description specific to this audience, I've
been having trouble connecting to MS SQL Server on CentOS 7 with
unixODBC and FreeTDS using the SQLDriverConnect function, while
connecting with the SQLConnect function works just fine.

I'm wondering if this is a bug in either the version of FreeTDS
included in the CentOS 7 EPEL or the version of unixODBC included in
the main CentOS 7 repository.

The versions of the libraries involved are:

[gmontee <at> localhost ~]$ sudo yum list unixODBC*
Installed Packages
unixODBC.x86_64

2.3.1-10.el7
                                                        <at> anaconda
[gmontee <at> localhost ~]$ sudo yum list freetds*
Installed Packages
freetds.x86_64

0.91-12.git0a42888.el7
                                                                <at> epel

This problem can be demonstrated by:

(Continue reading)

sales | 30 Jan 01:36 2015

Compiling error on Ubuntu

I am compiling freetds from CVS like this
./configure --prefix= --with-tdsver=8.0 --enable-msdblib --with-unixodbc=$(odbc_config
--prefix) --enable-krb5
the configure command runs fine, but the make fails, as below

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include 
-I../../include -I/usr/include/krb5 -I/usr/include/et -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H
-DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=8 -I//include  -D_REENTRANT
-D_THREAD_SAFE -DDEBUG=1 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long -pthread
-g -O2 -Wdeclaration-after-statement -MT gssapi.lo -MD -MP -MF .deps/gssapi.Tpo -c -o gssapi.lo gssapi.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -I/usr/include/krb5
-I/usr/include/et -DUNIXODBC -DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG
-DSIZEOF_LONG_INT=8 -I//include -D_REENTRANT -D_THREAD_SAFE -DDEBUG=1 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wno-long-long -pthread -g -O2 -Wdeclaration-after-statement -MT gssapi.lo
-MD -MP -MF .deps/gssapi.Tpo -c gssapi.c  -fPIC -DPIC -o .libs/gssapi.o
gssapi.c:259:1: error: conflicting types for 'error_message'
 error_message(OM_uint32 e)
 ^
In file included from gssapi.c:57:0:
/usr/include/et/com_err.h:38:20: note: previous declaration of 'error_message' was here
 extern char const *error_message (long);
                    ^
make[4]: *** [gssapi.lo] Error 1
make[4]: Leaving directory `/usr/src/freetds/src/tds'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/freetds/src/tds'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/freetds/src/tds'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/freetds/src'
(Continue reading)

James K. Lowden | 27 Jan 03:48 2015

chapter next

Greetings All, 

I want to let everyone know just a little news about the FreeTDS
project from my perspective.  

Frediano has agreed to be the Project Maintainer and is in the process
of acquiring the requisite keys to the kingdom.  It's fitting; no one
has done more to make FreeTDS what it is today.  

I have faith that Frediano won't pull up the drawbridge, not that I mean
to cross it very much.  I know he's interested in fixing the overnight
snapshot process, and in more frequent releases.  There's quite a bit
of new functionality in the current development branch that I'm sure
will be welcome in a new release.  

It's been quite a ride.  The oldest FreeTDS message in my personal
archive dates from 2001, the first year of the Bush administration.  In
those days FreeTDS was very much a work in progress.  There was only
primitive BCP (no freebcp), incomplete type conversion, just the most
essential functions.  The most frequent error was a TDS parsing error
about invalid stream state, leading immediately to exit(3).  

I remember an early bug report that said char-> int conversion failed
to read the last character, leading to the mother of all off-by-one
errors: off by one order of magnitude.  I think that was the day I
decided to jump in with both feet, starting with an all-to-all db-lib
type conversion test.  :-)

Even though my name is on a lot of email messages, I don't lay claim to
most of the code.  Much, much more was done by Brian & company in the
(Continue reading)

LacaK | 19 Jan 11:56 2015
Picon

Next stable release

Hi,
is there any plan, or time estimation for next (post 0.91) stable 
release of FreeTDS ?
(as it is more than 3 years after 0.91 was released)
If not, then is current git master stable enough?
(or are there any work in progress changes?)
Thanks
-Laco.
Gregory Holtorf | 16 Jan 23:17 2015
Picon

Adding NVARCHAR columns causes ct_cancel (ctlib) to hang

When calling ct_cancel in the freetds library, on unix, ct_cancel()
sometimes takes several minutes to run. This is bad because it usually
takes a few milliseconds to run. This bug works on freetds-0.91 and
freetds-0.64 In order to reproduce the bug, I needed to:

1. Run a select statement on a large table

2. The table has to contain nvarchar columns. varchar columns do not
trigger the bug.

3. The select statement must contain an order by clause

  select <nvarchar columns>

  from <table name>

  order by <nvarchar column>

After completing the select statement, call ct_cancel(). For instance,
before you make another select statement or when you log out.

  ct_cancel(m_pCtConnection, NULL, CS_CANCEL_ALL);

When I turn on logging I can see that after I call ct_cancel() for the last
time, it is followed by an absolutely huge number of packets received.  I
attached a log file, but I had to force quit the program or else the log
file ends up being several thousand megabytes long.

Is there a way to fix this issue? Is freetds unable to make select
statements on nvarchar columns or is it something I did in my code?
(Continue reading)

Velichko Yuriy | 16 Jan 08:12 2015
Picon

How to hash of the password string for query?

Hello! Sorry if this question is offtop in this list, but I hope that you
can help me.

I use freetds to communicate with SQL Server.
To create a server login I should to use query

CREATE LOGIN ... PASSWORD hashed_password HASHED

Advise me, please, how should I get the hashed_password properly? May be
there is a particular function in freetds for this purpose?

Thanks!
Adrian.Nye@dimensional.com | 6 Jan 16:32 2015

Unexpected EOF


Hello, I’m a first time poster to this list.

I am having a problem running TDS 0.91 on Mac OSX 10.9 (Mavericks) using a homebrew installation, where I can
no longer connect to Microsoft SQL.    The connection was working fine, but some unknown change broke it, and
I cannot seem to recover.

I did a brew update, then reinstalled unixodbc first, then reinstalled freetds with the —with-unixodbc option.

The output of tsql –C is:

                            Version: freetds v0.91
             freetds.conf directory: /usr/local/Cellar/freetds/0.91_2/etc
     MS db-lib source compatibility: no
        Sybase binary compatibility: no
                      Thread safety: yes
                      iconv library: yes
                        TDS version: 7.1
                              iODBC: no
                           unixodbc: yes
              SSPI "trusted" logins: no
                           Kerberos: no

I am using the following command for testing:

TDSVER=7.1 TDSDUMP=/tmp/freetds.log tsql -H <host> -p 1433 -U <username> -P  <pw>

I have confirmed using telnet that I can connect to the MSSQL server on port 1433.

The TDSVER, host, username, password, and port are all known correct because this command line works on
(Continue reading)


Gmane