Skip to Content.
Sympa Menu

freetds - Re: [freetds] parameters

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Gunther Van Butsele" <gvb AT velleman.be>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] parameters
  • Date: Mon, 28 Apr 2008 08:45:50 +0200


Thank you for this information. I had also already read this FAQ, but it
merely states the problem, not a clear solution, which is probably why a
lot of people keep struggling. From what I understand freetds needs to
be compiled with db-lib instead of ct-lib.

This should explain how to build with db-lib:
http://www.freetds.org/userguide/php.htm.

I'll be testing this soon.

Kind regards, (and kudos to this mailing list for the fast and helpful
responses!)
Gunther

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: donderdag 24 april 2008 21:08
To: FreeTDS Development Group
Subject: Re: [freetds] parameters

Federico Alves wrote:
> I execute a SQL 2005 stored procedure
> using perl, DBD-Sybase 1.08 and DBI 1.604. My freedts version is RC4
> or RC2. If I define my server in freetds.conf and include "tds
> version=8.0", the parameters do not get filled up. If I remove the
> line "tds version", the parameters work again, ceteris paribus.

http://www.freetds.org/faq.html#ms.output.parameters

Thank you for pointing this out. The FAQ could be clearer.

SP3 causes the server not to pass back output parameter data for TDS
7.0+ connections unless the RPC functions are used. TDS 4.2 clients are
unaffected.

You can demonstrate this yourself using fisql or any other interactive
SQL client. Invoke a procedure with an output parameter using each
protocol
version:

1> declare @a int
2> execute myproc @a output
3> go

and look at the TDSDUMP log output. You'll see the 4.2 log has an
output parameter packet and the 7.0 does not:

$ awk -F ' is ' '/marker/ {print $2}' dump.42 > marker.42 $ awk -F ' is
' '/marker/ {print $2}' dump.70 > marker.70 $ diff -u marker.42
marker.70
--- marker.42 2008-04-24 14:17:18.000000000 -0400
+++ marker.70 2008-04-24 14:17:29.000000000 -0400
@@ -2,21 +2,22 @@
ab(INFO)
e3(ENVCHANGE)
e3(ENVCHANGE)
+ab(INFO)
+e3(ENVCHANGE)
fd(DONE)
e3(ENVCHANGE)
e3(ENVCHANGE)
ab(INFO)
ab(INFO)
+ e3(ENVCHANGE)
+e3(ENVCHANGE)
fd(DONE)
fd(DONE)
ff(DONEINPROC)
ff(DONEINPROC)
79(RETURNSTATUS)
- ac(PARAM)
^^^^^ output parameter packet
- fe(DONEPROC)
fe(DONEPROC)

Using DBD::Sybase, there's no way anymore to get output parameter data
with modern Microsoft servers. Merely embedding the EXEC in the SQL
doesn't work, as we know. And a placeholder (parameter binding) doesn't
work, because the ct-lib API relies on features not present in a
Microsoft server to determine the SQL datatype of the parameter. (ODBC
parameter binding works because that information is provided by the
caller.)

To fix DBD::Sybase parameter binding, we've been waiting for the
improbable: either server-side support or client-side SQL parsing.
Lately I've been thinking we could extend the ct-lib API instead, adding
an ODBC-like parameter binding function. Of course, to take advantage
of it would mean altering DBD::Sybase and calling applications, but it
would finally close the last big gap -- placeholder support -- for
DBD::Sybase on Microsoft servers,

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page