Re: parameters

"Gunther Van Butsele" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.