Skip to Content.
Sympa Menu

freetds - Re: Future implementation

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Future implementation
  • Date: Tue, 24 Sep 2002 16:00:48 +0200


>
> > 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.
>

Correct, same behaviour of ms odbc

> 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).
>

How can I bind a parameter without type ??

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

Many people use ODBC with DBD::ODBC, so seem a good test. But I think
finally to provide a fill ODBC implementation...

> 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.
>

If I try to exec SQLDesbribeParam on "create table #test(a int, b
varchar(10)) insert into #test(a,b) values(?,?)" it return "invalid columns
number" (??? strange error...). When I exec SQLDesbribeParam on "insert into
#test(a,b) values(?,?)" it return right information..

I think first point it to change tds_dynamic_* function for supporting
TDS7/8 (and perhaps 4.2 but do not seem so useful) using RPC, then rebuild
ODBC prepare stuff using dynamic query...

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================




Archive powered by MHonArc 2.6.24.

Top of Page