gmane.comp.db.tds.freetds

Finding the FreeTDS ODBC driver

Jeff Dyson — 2008-12-04T00:54:43

Hello, I am working on a Linux box that was previously configured with FreeTDS. An IT admin has "proven" that the box can communicate with SQL Server by successfully connecting to the database with the tsql command. My questions are - Does a successful tsql connection confirm that a FreeTDS ODBC driver is installed on the box? If so, is there a way to determine which ODBC driver is in use by the tsql command? I am new to FreeTDS. I have read the FreeTDS User Guide but cannot find some of the files or directories referenced in the doc. These missing items make me suspicious that the ODBC driver is not installed and that tsql does not require an ODBC driver. For example: * There is no "freetds" directory on the box as referenced in the section about setting environment variables. * This "freetds" directory is also referenced in the DSN-less configuration section in the Driver= example for the odbcinst.ini file. * The driver named in the Driver= parameter is libtdsodbc.so. My

Re: Memory leak or memory accumulation with freetds-0.82 ctlib's ct_cmd_alloc / ct_cmd_drop?

2008-12-01T20:01:14

Hi freddy77, Ran valgrind and purify against ctlib_leak...no memory leaks found. After further investigation, the allocated memory (via ctlib_leak) is going into the cache pool, so my memory leak must be elsewhere (not in the ctlib_leak source code). I'll expand my search to the rest of my source code again. Thanks for the assistance and for pointing me to valgrind. I've used purify, but hadn't used valgrind before. Cheers, mtbrown88 ----- Original Message ----- From: "Frediano Ziglio" gmail.com> To: "FreeTDS Development Group" lists.ibiblio.org> Sent: Saturday, November 29, 2008 3:49:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [freetds] Memory leak or memory accumulation with freetds-0.82 ctlib's ct_cmd_alloc / ct_cmd_drop? Il giorno gio, 27/11/2008 alle 17.01 +0000, mtbrown88< at >comcast.net ha scritto: Could you try to install valgring and execute a valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 ./ctlib_leak it

Re: parameter cannot return more than 256 chars

Frediano Ziglio — 2008-12-01T14:51:03

2008/11/30 Federico Alves minixel.com>: After some tests is better to use DBD::ODBC #!/usr/bin/perl use strict; use DBI; my $dbh = DBI->connect("dbi:ODBC:TESTSRV", 'test', 'test', {PrintError => 0}) or die "Unable for connect to server $DBI::errstr"; $dbh->do("CREATE PROC #testsql \< at >s VARCHAR(512) OUTPUT AS SET \< at >s = REPLICATE(\< at >s, 100) + 'a'"); my $sth = $dbh->prepare('{call #testsql(?)}'); my $s = 'hello'; $sth->bind_param_inout(1, \$s, 512); $sth->execute; print "len=".length($s)." s=$s\n"; freddy77

Re: parameter cannot return more than 256 chars

Frediano Ziglio — 2008-12-01T13:12:06

2008/11/30 Federico Alves minixel.com>: This work #!/usr/bin/perl use strict; use DBI; my $server = ""; my $db = "minixel"; my $username = "sa"; my $password = ""; my $dbh = DBI->connect("dbi:Sybase:minixel:1433", 'user', 'pwd', {PrintError => 0}); die "Unable for connect to server $DBI::errstr" unless $dbh; $dbh->do("use $db"); # exec testsql \< at >sessionid , \< at >IPAddress OUTPUT, \< at >ReceivedNumber OUTPUT, \< at >ANI OUTPUT , \< at >protocol OUTPUT, \< at >timeout OUTPUT my $query = "exec testsql ?, ? output, ? output, ? output, ? output, ? output"; my $sth = $dbh->prepare($query); $sth->execute('1120019620.8','','17274907253','16463835040',1,0); my (< at >data) = $sth->syb_output_params(); print "data ".join(' ',< at >data)."\n"; do { while(my $dat = $sth->fetch) { print "TYPE $sth->{syb_result_type}\n"; print "Data < at >$dat[0] , < at >$dat[1] , < at >$dat[2] \n"; if($sth->{syb_result_type} == 4042) { # it's a PARAM result print "Number: $dat->[0] \n"; print "Varpar: $dat->[1] \n";

Re: parameter cannot return more than 256 chars

Frediano Ziglio — 2008-12-01T08:56:19

2008/11/30 Federico Alves minixel.com>: Configuring with tds version 8.0 change only the default, you can always override it. I would change script to use DBD::ODBC, probably there is something wrong with CTLib. It's not a emulation, server support both protocol 8.0 and earlier. This query can't work using protocol 8.0 !!! Output parameters are not returned to client using exec command. Microsoft change this behavior so or you use select after exec (like in tsql test) or you use protocol 4.2 (limiting varchar to 255 characters) or you use RPC directly (I don't know how to use it using DBD::Sybase, using DBD::ODBC you have to prepare a "{call sp?name(parameters)}" query binding with output specification) freddy77

parameter cannot return more than 256 chars

Federico Alves — 2008-11-30T18:44:16

This is the issue that has been killing me. If I set tds_version=8.0 in freetds.conf, then my perl does not pass any parameter at all. If I remove the tds_version from the server definition in freetds, then the parameters pass back and forth, but only 256 chars. You are right that the information works fine with tds_version=8.0, but then how do I make my perl script work again? This has been happening for ever. The only way to make my perl script work, which uses DBI and DBD-Sybase 8.0, is to remove the tds_version from freetds.conf and thus I guess it goes back to 4.2. But It makes little sense anyway because I compiled freetds with version 8.0 tsql -C Compile-time settings (established with the "configure" script) Version: freetds v0.82 freetds.conf directory: /usr/etc MS db-lib source compatibility: yes Sybase binary compatibility: no Thread safety: yes iconv library: yes TDS version:

Re: FreeTDS dbwillconvert discrepancy

Joe Losco — 2008-11-30T16:37:27

James K. Lowden wrote: I have thought about this a little more and have thought of something I had "fixed" for Obj-C that I thought was irrelevant, however now with the information about the results that dbwillconvert is returning and the possible issue of the bool, it may not be so irrelevant. When I first compiled the sample program in Obj-C, I had a conflicting declaration of Bool. One was in the FreeTDS header and the other was in the main objective-c header file. I had added a directive to not declare the bool in the FreeTDS header like the other ones were already there to avoid redeclaring it. What I added in the FreeTDS header was to the end of the !defined parts for the bool was as follows. This allowed the program to compile without any errors. && !defined(OBJC_BOOL_DEFINED) But what made me think of it now, is that objc.h declared the bool differently than FreeTDS. This to me is most likely the issue in Obj-C with dbwillconvert. FreeTDS defines the bool as typedef int

Re: SP parameter cannot return more than 256 chars

Frediano Ziglio — 2008-11-30T16:22:08

Il giorno dom, 30/11/2008 alle 10.57 -0500, Federico Alves ha scritto: Hi, are you sure you are using the proper protocol version ?? I got correct reply using 8.0 and 7.0, not using 4.2. freddy77

SP parameter cannot return more than 256 chars

Federico Alves — 2008-11-30T15:57:32

Freetds has a bug or a limitation I execute this query on tsql: "declare < at >iplist varchar(512),< at >z int exec tempdb.dbo.sip_redirect 44, < at >iplist out, < at >z out select < at >iplist,< at >z" but I only get back the first 256 characters on the variable < at >iplist, the rest is ignored, but I need the full 512 or more characters. How can we fix this limitation? I use the latest stable version. Parameter passing should be limited I guess to 64 K if possible.

Re: FreeTDS dbwillconvert discrepancy

Joe Losco — 2008-11-30T15:46:53

James K. Lowden wrote: No problem at all, I was just confused by the documentation that I had found later. I am linking to a compiled framework however it is the same framework for both the C and the Obj-C version. This is probably what is happening as it makes the most sense. No glue code is needed. Obj-C can directly call all C programs and all C code is valid Obj-C code. But what you said about Obj-C interpreting any non zero value as true makes the most sense to me. What I wonder then is there something I can do to make this work without having to change the FreeTDS headers (because I would assue a type change would be a recompile and change to the actual library? I am relatively new to C and ObjC, so I'm not too experienced in this department. No problem, glad I could help, and thanks for the feedback :) Joe

Re: Newbie php_dblib.dll

James K. Lowden — 2008-11-30T02:12:35

... It appears the server is not listening on the loopback address at that port for TCP connection. (Sadly, Windows seems not so set the error code such that strerror(3) can interpret it.) Perhaps: 1. the server is not listening on that interface, or 2. it's not accepting tcp/ip connections (named pipe only) Later releases are better, but I can't point you to a DLL. HTH. --jkl

Re: Data-conversion resulted in overflow using FreeTDS and SQLServer

James K. Lowden — 2008-11-30T02:00:56

... $ fisql -S $S -U $U -P $P 1>> select getdate() as today 2>> go today -------------------------- Nov 30 2008 12:51PM (1 rows affected) 1>> Is your default datetime conversion string format different from mine? A quick scan of the code shows only one call to dbconvert(), and the target buffer size is 512 bytes, a mighty big date. I'd expect a TDSDUMP log to be informative. --jkl

Re: FreeTDS/unixODBC Best Practices

James K. Lowden — 2008-11-30T01:49:12

Differences in configuration have a negligible effect on performance. Performance is dominated by server response time. Frediano refers to the extra round-trip needed to determine the port number from the instance name. Just as a DNS server converts the servers's hostname to an IP address, so too does the SQL Server convert the instance name to a port number. That can take a few milliseconds. If you have many, many brief sessions executing quick queries, that might matter. --jkl

Re: possible corruption of TDS 5.0 login packet

James K. Lowden — 2008-11-30T01:43:32

It doesn't happen to you on a TDS 5.0 connection? You log shows the [servername] from freetds.conf? Mine always says "SYBASE" in that field of the login packet. --jkl

Re: FreeTDS dbwillconvert discrepancy

James K. Lowden — 2008-11-30T01:38:53

Yes, that's my code. db-lib as specified and implemented by the vendors offers no way to discover the printed length of a non-character value. FreeTDS extends dbwillconvert() to do that: instead of a simple boolean, it returns the number of bytes needed for a character representation. I'm sorry it's not better documented. :-( My first instinct was to wonder if in fact you're linking to FreeTDS and not one of the vendor libraries, or perhaps to a version prior to 0.82. I assume none of those is the case. My second guess is to wonder if Objective C is looking at the header file (or something like that), interpreting each nonzero return code as "true", and returning only 0 or 1. Is there glue code that allows Objective C to call a C library? Is there some preprocessing that gets done to make C functions available to it? If so, the solution might be to define the function as returning DBINT instead of DBBOOL. Or something like that. Ouch. Yes. I'll update that. Thanks for pointing it ou

Re: Need some help connectiing to MSSQL with tsql

James K. Lowden — 2008-11-29T23:52:56

I wonder if HP/UX is unhappy with tds_iconv *writing* to errno? E.g., src/tds/iconv.c:655: if (conv->flags & TDS_ENCODING_MEMCPY || cd == invalid) { size_t len = *inbytesleft < *outbytesleft ? *inbytesleft : *outbytesleft; memcpy(*outbuf, *inbuf, len); errno = *inbytesleft > *outbytesleft ? E2BIG : 0; --jkl

Re: Freetds connection problem

James K. Lowden — 2008-11-29T23:47:09

... The tds7_get_instance_port dialog, above, shows FreeTDS interrogating the server for the port associated with the "SL" instance. There is no NACK ("what are you talking about") kind of reply in the protocol for this kind of request; the server simply ignores invalid requests. If you are sure 192.168.10.50 is the right address, are you sure "SL" is the right instance name? When you log in via Microsoft's tool, what does select < at >< at >servername return? http://support.microsoft.com/kb/313225 To find the SQL Server instance port number, follow these steps: 1. On the Microsoft SQL Server 2000 server, start the SQL Server Network Utility. 2. Click the General tab, and then click the instance you want from the Instances drop-down menu. 3. Click TCP/IP, and then click Properties. Note that the port number for this instance appears in the Properties dialog box. You should be able to telnet to the port. HTH. --jkl

Re: Problem compiling DBD::Sybase using freetds (MacOS 10.5.5, Fedora 10)

James K. Lowden — 2008-11-29T22:40:00

... No. We maintain a patched distribution at http://ibiblio.org/pub/Linux/ALPHA/freetds/stable. It includes all commits to the release branch to date. (The system that updates patched release is new and doesn't always detect when a new patched distribution needs to be created, but what's there definitely includes the BLK patch. HTH. --jkl

Re: Freetds connection problem

Franck Y — 2008-11-29T14:49:57

Oh how can i see the port number of the instance ?

Re: dblib unit tests

Frediano Ziglio — 2008-11-29T09:55:55

Il giorno lun, 24/11/2008 alle 17.36 -0500, James K. Lowden ha scritto: well... I see the changes and I can't see many changes in unittests in order to compile under windows... good! I think so. Well... I know :) ODBC is now more test-driven. Actually I check ODBC unitest under windows about every month. I found a winexec command under Linux that could help me to script everything. Some tests fails some cause MS ODBC seems less ODBC-compliant compared to our driver (believe or not!) and something for sligtly difference (so small that former MS ODBC passed...) I don't think Ted problem require many changes (I don't think libTDS will change...). Perhaps is time to see done_handling test again... this test... is not a test... it do some test but what it lack is results checking... it mainly prints the state of dblib after every operation without checking a given state, so it returns always success. Many time ago (more than a year I think) I managed to add state test and fix our dblib (results printed was

Re: FreeTDS dbwillconvert discrepancy

Frediano Ziglio — 2008-11-29T09:37:59

Il giorno mer, 26/11/2008 alle 12.56 -0500, Joe Losco ha scritto: It returns a bool, you could see vendors (Sybase or MS) documentation (ie http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/< at >ebt-link;pt=2814?target=%25N%15_45151_START_RESTART_N%25) freddy77