[freetds] Using sp_executesql with Microsoft SQL Server 2000

[Staats, Frederick W]

Has anyone on the freeTDS team looked at using sp_executesql in
freeTDS for parameter passing using freeTDS with Microsoft SQL
Server 2000?

It turns out that Microsoft SQL 2000 internally uses a system
stored procedure called sp_executesql for runtime bound SQL
statements (both the OLE DB and ODBC Libs use this internally.)
An example statement looks like:

EXECUTE sp_executesql
N'INSERT INTO odbctest.odbctest.test (foo, bar) VALUES (@key1, @key2)',
N'@key1 INT, @key2 TEXT',
@key1 = 1,
@key2 = 'abc'

Where the first argument is the SQL to execute, the second is
the types of the arguments and the third are the local
temporary values to assign (they are privately scoped inside
sp_executesql stored procedure.

The advantage of this procedure is that the text of the embedded
SQL statement matches exactly every time speeding up the
optimization engine in the SQL server. (No fancy pattern
matching needed to determine if it can reuse an execution plan.)

The only real limit I've seen in the docs so far is that all objects
(TABLES, VIEWS, etc.) must be fully qualified (eg.
database.owner.table) for the optimization engine to match using
sp_executesql.

I'm working on an optional perl only extension to DBD::Sybase
that will allow me to do '?' based parameter passing using
this technique, but am wondering if anyone has looked a
lower level interface.

[Rogers, Tom]

Recently we had issues with the current FreeTDS implementation working with
UnixODBC in that we were not getting stored procedure output parameters
returned. The issues surrounding output parameters and TDS and how
Microsoft changed things around SQL 7.0 timeframe are pretty well documented
in the archive so I won't digress.

However, to answer your specific question dealing with the use of
sp_executesql for parameter passing, though I think on the surface it is a
good idea for the reasons you state, just be aware that I don't think said
system SP supports output parameters; at least last time I tried I couldn't
get them to work. It seems that the parameters that the system SP take are
only for input. So, that could be a limitation, depending on your needs.

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: Staats, Frederick W [mailto:frederick.w.staats at intel.com]
Sent: Monday, June 30, 2003 11:47 AM
To: freetds at lists.ibiblio.org
Subject: [freetds] Using sp_executesql with Microsoft SQL Server 2000


Has anyone on the freeTDS team looked at using sp_executesql in
freeTDS for parameter passing using freeTDS with Microsoft SQL
Server 2000?

It turns out that Microsoft SQL 2000 internally uses a system
stored procedure called sp_executesql for runtime bound SQL
statements (both the OLE DB and ODBC Libs use this internally.)
An example statement looks like:

EXECUTE sp_executesql
N'INSERT INTO odbctest.odbctest.test (foo, bar) VALUES (@key1, @key2)',
N'@key1 INT, @key2 TEXT',
@key1 = 1,
@key2 = 'abc'

Where the first argument is the SQL to execute, the second is
the types of the arguments and the third are the local
temporary values to assign (they are privately scoped inside
sp_executesql stored procedure.

The advantage of this procedure is that the text of the embedded
SQL statement matches exactly every time speeding up the
optimization engine in the SQL server. (No fancy pattern
matching needed to determine if it can reuse an execution plan.)

The only real limit I've seen in the docs so far is that all objects
(TABLES, VIEWS, etc.) must be fully qualified (eg.
database.owner.table) for the optimization engine to match using
sp_executesql.

I'm working on an optional perl only extension to DBD::Sybase
that will allow me to do '?' based parameter passing using
this technique, but am wondering if anyone has looked a
lower level interface.

[Lowden, James K]

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: June 30, 2003 12:36 PM
However, to answer your specific question dealing with the use of
sp_executesql for parameter passing, though I think on the
surface it is a
good idea for the reasons you state, just be aware that I
don't think said system SP supports output parameters

Thomas,

sp_executesql returns output parameters:

1> declare @b smallint
exec sp_executesql N'select @a=1',
N'@a int output',
@a=@b output
select @b
2> go

------
1

(1 row affected)

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.

[Lowden, James K]

Post by Rogers, Tom
From: Staats, Frederick W [mailto:frederick.w.staats at intel.com]
Sent: June 30, 2003 11:47 AM
Has anyone on the freeTDS team looked at using sp_executesql in
freeTDS for parameter passing using freeTDS with Microsoft SQL
Server 2000?

...

Post by Rogers, Tom
I'm working on an optional perl only extension to DBD::Sybase
that will allow me to do '?' based parameter passing using
this technique, but am wondering if anyone has looked a
lower level interface.

DBD::Sybase uses ct-lib. I think current ct-lib in CVS supports '?'
placeholders via ct_send_dyn(). I don't know how well it works. I don't
see a unit test for it, and it hasn't been crossed off the TODO. In any
case, all the hard parts are done in libtds, and placeholders work at least
somewhat in ODBC.

Frediano reverse engineered the TDS 7.0 protocol for dynamic SQL. IIRC, his
work is based on the RPC protocol. It doesn't look like he uses
sp_executesql. I don't know why; I don't recall any discussion about it. I
wonder if he ever came across it in his traces.

If the ct-lib support for placeholders is lacking in some area that you need
to make DBD::Sybase work correctly with FreeTDS, please tell us, if you can,
specifically what's missing. Perhaps we can work together to fill in the
blanks. At the very least we can make the TODO more detailed.

BTW, Bill Thompson is planning enhancements to ct-lib. I'm very eager to
see DBD::Sybase work perfectly with FreeTDS, and I expect that Bill's work
will carry us most the way there, quite possibly all the way there. (Yay,
Bill!)

I suppose it's obvious, but I'll say it anyway: patches welcome. :-)

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.

[Rogers, Tom]

I stand corrected...I tried it several times, but I kept getting it wrong,
and the books online for this are very poor.

I tried the following (like your example but with one less var):
declare @a smallint
exec sp_executesql N'select @a=2',
N'@a int output', @a
select @a

expecting it to work...but it did not.

Seems I needed YET ANOTHER "output" statement:

declare @a smallint
exec sp_executesql N'select @a=2',
N'@a int output', @a output
select @a

The above works as expected.

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Monday, June 30, 2003 4:56 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: June 30, 2003 12:36 PM
However, to answer your specific question dealing with the use of
sp_executesql for parameter passing, though I think on the
surface it is a
good idea for the reasons you state, just be aware that I
don't think said system SP supports output parameters

Thomas,

sp_executesql returns output parameters:

1> declare @b smallint
exec sp_executesql N'select @a=1',
N'@a int output',
@a=@b output
select @b
2> go

------
1

(1 row affected)

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

[James K. Lowden]

On Mon, 30 Jun 2003 18:27:04 -0400, "Rogers, Tom" <tom.rogers at ccur.com>

Post by Rogers, Tom
expecting it to work...but it did not.

Tom,

I see your confusion. You have to imagine what sp_executesql is doing,
and be very familiar with parameter passing, to understand why that
wouldn't work.

Recall that for any stored procedure, you can pass parameters by name or
position. For a simple procedure

create proc a @a int as select @a as '@a'

you could call it as:

execute a 1
or
execute a @a=1

In either case, you're passing a constant (1) to the procedure.

A separate and distinct rule is that output parameters need "out[put]"
twice to work. Modify things slightly

create proc a @a int output as
select @a=9

if you call it as:

execute a 1
or
execute a @a=1

you're still passing a constant. The server won't attempt to write to it,
though, even though the procedure declares the parameter for output,
because it's being passed by value. To pass it by reference, you need the
"output" keyword. Pretty much everyone tries this at least once:

execute a @a=1 output

and gets a complaint about not being able to write to a constant. The
constant it's talking about is that 1, passed by value. (The @a is the
name of the parameter.) The server is trying to do something like

select 1=9

which obviously won't do at all. Instead, you have to give it a variable
to write to, the *caller's* variable, by reference:

declare @b int
execute a @b output -- or
execute a @a=@b output

passing @b by reference, either way.

Now we see the logic inherent in the system. sp_executesql forms a stored
in effect passed @a by position and by value:

1. create proc X @a int output as
select @a=2
2. declare @a smallint
3. execute X @a

whereas what you wanted was:

execute X @a output

as in your successful test. :-) Note you have two @a variables -- the
procedure's and the caller's -- and you have passed the caller's, by
position.

I don't know if any of this is any real use to you or the project, but I
hope at least I've alleviated your confusion.

Regards,

--jkl

[ZIGLIO Frediano]

Post by Rogers, Tom

Post by Staats, Frederick W
Has anyone on the freeTDS team looked at using sp_executesql in
freeTDS for parameter passing using freeTDS with Microsoft

SQL Server

Post by Staats, Frederick W
2000?

...

Post by Staats, Frederick W
I'm working on an optional perl only extension to DBD::Sybase that
will allow me to do '?' based parameter passing using this

technique,

Post by Staats, Frederick W
but am wondering if anyone has looked a lower level interface.

DBD::Sybase uses ct-lib. I think current ct-lib in CVS
supports '?' placeholders via ct_send_dyn(). I don't know
how well it works. I don't see a unit test for it, and it
hasn't been crossed off the TODO. In any case, all the hard
parts are done in libtds, and placeholders work at least
somewhat in ODBC.
Frediano reverse engineered the TDS 7.0 protocol for dynamic
SQL. IIRC, his work is based on the RPC protocol. It
doesn't look like he uses sp_executesql. I don't know why; I
don't recall any discussion about it. I wonder if he ever
came across it in his traces.

?? Code in in CVS since a month... in query.c (search
"s\0p\0_\0e\0x\0e\0c\0u\0t\0e\0s\0q\0l").
I think only ct-lib can use this stuff and I don't know if it work
well...

bye

[ZIGLIO Frediano]

Post by James K. Lowden
On Mon, 30 Jun 2003 18:27:04 -0400, "Rogers, Tom"
<tom.rogers at ccur.com>

Post by Rogers, Tom
expecting it to work...but it did not.

Tom,
I see your confusion. You have to imagine what sp_executesql
is doing, and be very familiar with parameter passing, to
understand why that wouldn't work.
Recall that for any stored procedure, you can pass parameters
by name or position. For a simple procedure
execute a 1
or
In either case, you're passing a constant (1) to the procedure.
A separate and distinct rule is that output parameters need
"out[put]" twice to work. Modify things slightly
execute a 1
or
you're still passing a constant. The server won't attempt to
write to it, though, even though the procedure declares the
parameter for output, because it's being passed by value. To
pass it by reference, you need the "output" keyword. Pretty
and gets a complaint about not being able to write to a
constant. The constant it's talking about is that 1, passed
is trying to do something like
select 1=9
which obviously won't do at all. Instead, you have to give
Now we see the logic inherent in the system. sp_executesql
forms a stored procedure from its parameters, and then
variables -- the procedure's and the caller's -- and you have
passed the caller's, by position.
I don't know if any of this is any real use to you or the
project, but I hope at least I've alleviated your confusion.
Regards,

I think that you can use RPC directly and not pass names...

freddy77

[ZIGLIO Frediano]

Post by Rogers, Tom
Recently we had issues with the current FreeTDS
implementation working with UnixODBC in that we were not
getting stored procedure output parameters returned. The
issues surrounding output parameters and TDS and how
Microsoft changed things around SQL 7.0 timeframe are pretty
well documented in the archive so I won't digress.

Can you explain deeply your problems ??
How you call a stored procedure?
Output parameters should work in all library...

freddy77

[Rogers, Tom]

Up until about a month ago, we were told by several on this group that
FreeTDS would not support output parameters on MS SQL because of a change
Microsoft made in the way it handled output params, circa SQL 7.0, SPx. At
that time, they changed the output params such that they were being sent
"out of band" and not part of the normal messages returned (or something
like that).

We were using build 6.2, with UnixODBC on Linux, connecting to MS SQL 7.0.
And calling via the escape clause format of UnixODBC:

query = "{? = call mysp(?, ?, ?}"

Than, binding input/output, and input and output params via ODBC's
SQLBindParameter.

The SP would work, but output parameters would not be populated. We were
told by several, including you Frediano, if memory serves, that in order to
get this to work, some internals would have to change related to the use of
rpc, and that it was work in the queue.

That is the last I heard.

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: ZIGLIO Frediano [mailto:Frediano.Ziglio at vodafone.com]
Sent: Tuesday, July 01, 2003 8:37 AM
To: FreeTDS Development Group
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000

Recently we had issues with the current FreeTDS
implementation working with UnixODBC in that we were not
getting stored procedure output parameters returned. The
issues surrounding output parameters and TDS and how
Microsoft changed things around SQL 7.0 timeframe are pretty
well documented in the archive so I won't digress.

Can you explain deeply your problems ??
How you call a stored procedure?
Output parameters should work in all library...

freddy77

[Rogers, Tom]

Thanks...I am not a newbie to SPs but I do appreciate the depth of your
explanation. I had the one 'output', it just didn't occur to me to add the
second, but it makes perfect sense. The "syntax" of still seems very
strange, the double indirection nature and having to pass, and declare and
pass the vars twice is no doubt a necessary evil, but seems really strange
as I said.

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: James K. Lowden [mailto:jklowden at schemamania.org]
Sent: Monday, June 30, 2003 7:57 PM
To: FreeTDS Development Group
Subject: Re: [freetds] Using sp_executesql with Microsoft SQL Server
2000


On Mon, 30 Jun 2003 18:27:04 -0400, "Rogers, Tom" <tom.rogers at ccur.com>

expecting it to work...but it did not.

Tom,

I see your confusion. You have to imagine what sp_executesql is doing,
and be very familiar with parameter passing, to understand why that
wouldn't work.

Recall that for any stored procedure, you can pass parameters by name or
position. For a simple procedure

create proc a @a int as select @a as '@a'

you could call it as:

execute a 1
or
execute a @a=1

In either case, you're passing a constant (1) to the procedure.

A separate and distinct rule is that output parameters need "out[put]"
twice to work. Modify things slightly

create proc a @a int output as
select @a=9

if you call it as:

execute a 1
or
execute a @a=1

you're still passing a constant. The server won't attempt to write to it,
though, even though the procedure declares the parameter for output,
because it's being passed by value. To pass it by reference, you need the
"output" keyword. Pretty much everyone tries this at least once:

execute a @a=1 output

and gets a complaint about not being able to write to a constant. The
constant it's talking about is that 1, passed by value. (The @a is the
name of the parameter.) The server is trying to do something like

select 1=9

which obviously won't do at all. Instead, you have to give it a variable
to write to, the *caller's* variable, by reference:

declare @b int
execute a @b output -- or
execute a @a=@b output

passing @b by reference, either way.

Now we see the logic inherent in the system. sp_executesql forms a stored
in effect passed @a by position and by value:

1. create proc X @a int output as
select @a=2
2. declare @a smallint
3. execute X @a

whereas what you wanted was:

execute X @a output

as in your successful test. :-) Note you have two @a variables -- the
procedure's and the caller's -- and you have passed the caller's, by
position.

I don't know if any of this is any real use to you or the project, but I
hope at least I've alleviated your confusion.

Regards,

--jkl

[Lowden, James K]

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: July 1, 2003 9:04 AM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000
Up until about a month ago, we were told by several on this group that
FreeTDS would not support output parameters on MS SQL because
of a change
Microsoft made in the way it handled output params, circa SQL
7.0, SPx. At
that time, they changed the output params such that they were
being sent
"out of band" and not part of the normal messages returned
(or something like that).

Let me try to clarify that. :-)

Nick Castellano discovered that as of SQL Server 7.0 SP3, using TDS 7.0,
Microsoft stopped supporting output parameters embedded in SQL text. If you
sent

declare @a int
exec a @a output

prior to SP3, the server sent a special result set packet. With db-lib, the
application would call dbnumrets() and friends to fetch the output.
Starting with SP3, Microsoft simply ceased sending that special result set
packet; the same application would be told there were no output parameters
returned.

The remedy lay in the RPC protocol, which Frediano had begun to work on for
a different purpose, for placeholder support. In short order we were able
to add the db-lib and ct-lib RPC functions. If they're used, the server
will once again return the data. There are unit tests for both:

src/ctlib/unittests/rpc_ct_param.c
src/ctlib/unittests/rpc_ct_setparam.c
src/dblib/unittests/rpc.c
src/dblib/unittests/t0022.c

Microsoft's own db-lib uses TDS 4.2, which is unaffected. I'm not familiar
enough with the ODBC idiom to know whether or not it has any non-RPC way to
retrieve output parameter values. Perhaps the change affected no Microsoft
customers.

query = "{? = call mysp(?, ?, ?}"
From reading the ChangeLog, I doubt you can fetch output parameters that way

yet, but it looks close.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.

[Rogers, Tom]

So, then will this or won't this work with UnixODBC and the escape query
format?

We are not using FreeTds directly, but are using the UnixODBC interfaces and
code that calls SQLSetParameter, SQLExecute, and uses the "{? = call
myproc(?, ?)}}" syntax. I am not sure of the interaction with UnixODBC, and
FreeTDS, other than that when we built FreeTDS we instructed it that we were
using UnixODBC. I guess if the new RPC stuff is used transparently and
automatically at a low enough level, it would just "start to work" under
UnixODBC, but I don't know if that is the case.

I think you are saying it won't work????

Also, I suspect with MSFT made their change they also changed their ODBC
drivers accordingly.

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Wednesday, July 02, 2003 9:46 AM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: July 1, 2003 9:04 AM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000
Up until about a month ago, we were told by several on this group that
FreeTDS would not support output parameters on MS SQL because
of a change
Microsoft made in the way it handled output params, circa SQL
7.0, SPx. At
that time, they changed the output params such that they were
being sent
"out of band" and not part of the normal messages returned
(or something like that).

Let me try to clarify that. :-)

Nick Castellano discovered that as of SQL Server 7.0 SP3, using TDS 7.0,
Microsoft stopped supporting output parameters embedded in SQL text. If you
sent

declare @a int
exec a @a output

prior to SP3, the server sent a special result set packet. With db-lib, the
application would call dbnumrets() and friends to fetch the output.
Starting with SP3, Microsoft simply ceased sending that special result set
packet; the same application would be told there were no output parameters
returned.

The remedy lay in the RPC protocol, which Frediano had begun to work on for
a different purpose, for placeholder support. In short order we were able
to add the db-lib and ct-lib RPC functions. If they're used, the server
will once again return the data. There are unit tests for both:

src/ctlib/unittests/rpc_ct_param.c
src/ctlib/unittests/rpc_ct_setparam.c
src/dblib/unittests/rpc.c
src/dblib/unittests/t0022.c

Microsoft's own db-lib uses TDS 4.2, which is unaffected. I'm not familiar
enough with the ODBC idiom to know whether or not it has any non-RPC way to
retrieve output parameter values. Perhaps the change affected no Microsoft
customers.

query = "{? = call mysp(?, ?, ?}"
From reading the ChangeLog, I doubt you can fetch output parameters that

way
yet, but it looks close.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

[Lowden, James K]

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: July 2, 2003 9:55 AM
So, then will this or won't this work with UnixODBC and the
escape query format?

I don't know, Tom. I doubt it. I hope the ODBC folks will answer you
definitively, and that someone will contribute a unit test.

I am not sure of the interaction with UnixODBC, and
FreeTDS, other than that when we built FreeTDS we instructed
it that we were using UnixODBC.

AIUI, the driver manager is a thin layer over the ODBC driver, whose main
purpose is to isolate the various driver configuration idiosyncrasies from
the application.

I guess if the new RPC stuff is used transparently and
automatically at a low enough level, it would just "start to
work" under UnixODBC, but I don't know if that is the case.

That's our goal.

I think you are saying it won't work????

If "it" is output parameters in prepared ODBC statements, then, I'm afraid
it only almost works. I'm happy to be corrected.

Is it worth your while to put together a unit test? That would answer the
question, and if the answer is "no, still broken", we'd at least have a
baseline measure.

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions.

[Rogers, Tom]

Yes, it is worth our while. I have on my to-do list to get the latest drop
from CVS and test. We already have a simple test case. Just haven't had
the time to do the download, build, test.

Will provide more info when available.

THANKS!

Thomas Rogers
System Engineer
Concurrent Computer Corporation

phone: [phone] x7261

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Wednesday, July 02, 2003 2:18 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: July 2, 2003 9:55 AM
So, then will this or won't this work with UnixODBC and the
escape query format?

I don't know, Tom. I doubt it. I hope the ODBC folks will answer you
definitively, and that someone will contribute a unit test.

I am not sure of the interaction with UnixODBC, and
FreeTDS, other than that when we built FreeTDS we instructed
it that we were using UnixODBC.

AIUI, the driver manager is a thin layer over the ODBC driver, whose main
purpose is to isolate the various driver configuration idiosyncrasies from
the application.

I guess if the new RPC stuff is used transparently and
automatically at a low enough level, it would just "start to
work" under UnixODBC, but I don't know if that is the case.

That's our goal.

I think you are saying it won't work????

If "it" is output parameters in prepared ODBC statements, then, I'm afraid
it only almost works. I'm happy to be corrected.

Is it worth your while to put together a unit test? That would answer the
question, and if the answer is "no, still broken", we'd at least have a
baseline measure.

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.

[Frediano Ziglio]

Post by Rogers, Tom
Yes, it is worth our while. I have on my to-do list to get the latest drop
from CVS and test. We already have a simple test case. Just haven't had
the time to do the download, build, test.
Will provide more info when available.
THANKS!
Thomas Rogers
System Engineer
Concurrent Computer Corporation

News:
- Today I tested ODBC/RPC stuff :)
- I encountered some problem :(
- I'm doing some fix :) ...

freddy77

Post by Rogers, Tom

phone: [phone] x7261

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK at bernstein.com]
Sent: Wednesday, July 02, 2003 2:18 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] Using sp_executesql with Microsoft SQL Server
2000

From: Rogers, Tom [mailto:tom.rogers at ccur.com]
Sent: July 2, 2003 9:55 AM
So, then will this or won't this work with UnixODBC and the
escape query format?

I don't know, Tom. I doubt it. I hope the ODBC folks will answer you
definitively, and that someone will contribute a unit test.

I am not sure of the interaction with UnixODBC, and
FreeTDS, other than that when we built FreeTDS we instructed
it that we were using UnixODBC.

AIUI, the driver manager is a thin layer over the ODBC driver, whose main
purpose is to isolate the various driver configuration idiosyncrasies from
the application.

I guess if the new RPC stuff is used transparently and
automatically at a low enough level, it would just "start to
work" under UnixODBC, but I don't know if that is the case.

That's our goal.

I think you are saying it won't work????

If "it" is output parameters in prepared ODBC statements, then, I'm afraid
it only almost works. I'm happy to be corrected.
Is it worth your while to put together a unit test? That would answer the
question, and if the answer is "no, still broken", we'd at least have a
baseline measure.
--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds