Skip to Content.
Sympa Menu

freetds - Re: Future implementation

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Andrea Spinelli" <aspinelli AT imteam.it>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: Future implementation
  • Date: Tue, 24 Sep 2002 08:59:20 -0400



> ODBC (I don't know other api) have a function to return parameter type
> for dynamic query. This function is quite easy to implement on Sybase
> (Sybase return all parameter type) while hard on mssql, requiring
> parsing of query and get manually type of pararameters, see at
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/odbcsql/od_odbc_d_1not.asp

>From the [limited] point of view of DBD::ODBC, parameter
description is not strictly necessary. All is really needed
is to retrieve the parameter types from the bound variables,
which means that you have to actually prepare the statement
not at the SQLPrepare call, but at the first SQLExecute.

This is what I understand (by packet sniffing) the MS SQL Server
'official' driver is doing.

Moreover, using the MS driver, if you do not explicitly
bind variables with a type in a DBD::ODBC statement,
[using bind_param], the default type is used, which is,
apparently, varchar(80).

What I am trying to say is that if we limit ourselves to DBD:ODBC
"compliance", there are relatively little problems.

If, on the other hand,
we want to fully implement SQLDescribeParam, we have to completely
parse the SQL statement, or to accept some limitation on the syntax
which is handled. In the first hypotesis, I would like to
use an existing SQL parser, because I'm afraid that writing one
from scratch is unreasonable. In the latter hypotesis,
a consensus must be reached on what the limitations are.

Just some thoughts,
a.





Archive powered by MHonArc 2.6.24.

Top of Page