headers
Frediano Ziglio | 1 Dec 2008 09:56
Picon

Re: parameter cannot return more than 256 chars

2008/11/30 Federico Alves <sales <at> minixel.com>:
> 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
>

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.

> 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: 8.0
>                              iODBC: no
>                           unixodbc: yes
>
> Dear Frediano, can you please use your privileged mind and figure out why
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frediano Ziglio | 1 Dec 2008 14:12
Picon

Re: parameter cannot return more than 256 chars

2008/11/30 Federico Alves <sales <at> minixel.com>:
> 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: 8.0
>                              iODBC: no
>                           unixodbc: yes
>
> Dear Frediano, can you please use your privileged mind and figure out why
> this perl script works only in 4.2 emulation and not in 8.0? If you log into
> my server the script is located on /var/lib/asterisk/agi-bin
>
> #!/usr/bin/perl
>
> use strict;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frediano Ziglio | 1 Dec 2008 15:51
Picon

Re: parameter cannot return more than 256 chars

2008/11/30 Federico Alves <sales <at> minixel.com>:
> 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: 8.0
>                              iODBC: no
>                           unixodbc: yes
>
> Dear Frediano, can you please use your privileged mind and figure out why
> this perl script works only in 4.2 emulation and not in 8.0? If you log into
> my server the script is located on /var/lib/asterisk/agi-bin
>
> #!/usr/bin/perl
>
> use strict;
(Continue reading)

Permalink | Reply | 0 comments |
headers
mtbrown88 | 1 Dec 2008 21:01
Picon

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


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" <freddy77 <at> gmail.com> 
To: "FreeTDS Development Group" <freetds <at> 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: 
> 
> Hi freddy77, 
> 
> 
> 
> Thanks for testing it.  I am running Red Hat Enterprise Linux 4 Update 7 -- uname -a output: 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Dyson | 4 Dec 2008 01:54

Finding the FreeTDS ODBC driver

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 goal is to find this file, but it does not
exist on the system.

*         There is no "unittests" directory as referenced in the Confirming the Installation.

My tsql command is as follows:
tsql -S sql83 -U userid -P password -D _database_

When run, I see the message "Default database being set to _database_".  If I run tsql with a bogus database
name, I receive a 'Cannot open database...' message.  The sql83 server is defined in
/usr/local/etc/freetds.conf.  The [sql83] entry identifies the host, the port, and the tds version (8.0).
(Continue reading)

Permalink | Reply | 12 comments |
headers
Frediano Ziglio | 4 Dec 2008 11:08
Picon

Re: Finding the FreeTDS ODBC driver

Il giorno mer, 03/12/2008 alle 18.54 -0600, Jeff Dyson ha scritto:
> 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.
> 

no, tsql use libTDS, the core library, this means that you can have tsql
but not ODBC. You can also install our ODBC driver without tsql but if
you start from sources it's hard.

> For example:
> 
> *         There is no "freetds" directory on the box as referenced in the section about setting environment variables.
> 

you are right, /usr/local/freetds is used in these examples but default
is /usr/local

> *         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 goal is to find this file, but it does not
exist on the system.
(Continue reading)

Permalink | Reply | 10 comments |
headers
SICKINGER Manfred | 4 Dec 2008 16:00
Favicon

odbc specification

hello

which odbc specification does freetds-0.82 conform to (2.5 or 3.0) ?

regards,
manfred
Permalink | Reply | 1 comment |
headers
James K. Lowden | 4 Dec 2008 16:09

Re: Finding the FreeTDS ODBC driver

Jeff Dyson wrote:
> 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?

Strictly speaking, your admin is correct: tsql works, ipso facto the *box*
can communicate with the server.  

That says nothing about ODBC, though.  If your application needs an ODBC
driver, it needs an ODBC driver.  Without it, your *application* cannot
communicate with the server.  

ODBC is an optional part of a FreeTDS installation.  It sounds like yours
wasn't built or installed.  

There are two parts to an ODBC installation: the Driver Manager (DM) and
the driver itself.  The DM provides the header (.h) files that are used in
commmon between the DM, the driver, and the application.  (That way, all
three agree on, say, the integer value of SQL_SUCCESS_WITH_INFO or the
native machine type of DWORD.)  One important header file is sql.h,
commonly installed in /usr/local/include.  

The DM also mediates between the application and the driver, making the
drivers seem more uniform than they really are.  It's possible to build
and use the FreeTDS ODBC driver without a DM (though you still need the
DM's header files) but the resulting application is less portable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James K. Lowden | 4 Dec 2008 16:12

Re: odbc specification

SICKINGER Manfred wrote:
> 
> which odbc specification does freetds-0.82 conform to (2.5 or 3.0) ?

http://www.freetds.org/userguide/projects.htm#STATUS

	"The ODBC driver should be fully ODBC 3.0 compliant."

--jkl
Permalink | Reply | 0 comments |
headers
Kenneth Ng | 4 Dec 2008 18:54
Picon

Freetds Perl interface on Fedora 10

Has anyone been able to get Freetds to work with the perl DBD::Sybase
module on Fedora 10?  I'm following the instructions in the userguide,
here is a symopsis:

- Build Fedora 10 i686 version (X64_64 version had similar results)
- Yum install freetds, freetds-devel, freetds-doc
-  Found the libraries in /usr/lib, so I "export SYBASE=/usr"
- Got Sybase 1.09 from search.cpan.org, dezipped and untared
- Ran "perl Makefile.PL".
- ran make, go the following:
type 'CS_INT'
dbdimp.c: In function 'syb_init':
dbdimp.c:777: error: 'BLK_VERSION_150' undeclared (first use in this function)
dbdimp.c:777: error: (Each undeclared identifier is reported only once
dbdimp.c:777: error: for each function it appears in.)
dbdimp.c:781: error: 'BLK_VERSION_125' undeclared (first use in this function)
dbdimp.c:785: error: 'BLK_VERSION_120' undeclared (first use in this function)
dbdimp.c:724: warning: unused variable 'boolean'
dbdimp.c: In function 'get_server_version':
dbdimp.c:1567: warning: unused variable 'db'
Permalink | Reply | 5 comments |

Gmane