FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: November 26, 2002 11:36 AM
> 
> This patch solve RPC problem but open other possible problems... 
> - dynamic do not want column names on data

Do you mean:

1.  dynamic SQL doesn't require named parmeters
  or
2.  TDS 7.0 can't pass named parameters?  

TDS 4.2 and 5.0 do pass named parameters.  I would think 7.0 can, too.  From
the description of the ODBC API, though, it looks possible to support named
parameters _in_the_driver_, never passing them to the server.  

Do you need a trace of an MS ODBC TDS 7.0 conversation?  

ODBC defines a way to pass parameters by name:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/od
bcbinding_parameters_by_name__named_parameters_.asp

See also:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/od
bcdescriptors.asp

> - we do not use column_namelen (is this correct?)

I don't think any of us knows yet if it's correct or not.  :(

> - correct to use column_flags? 

Depends on the protocol; we'll have to experiment.  Certainly, 

+++

I've attached a note about SQLBindParameter from MSDN (ODBC Implementation
Details), in case you haven't seen it.  It supports output parameters.  

In db-lib, named parameter support in the protocol is required.  The app
calls dbrpcparam once for each parameter, but not in any particular order.
TDS 5.0 passes them by name; the server returns them by name.    Names are
not required (they can be passed positionally), but db-lib does not have
enough information to map names to positions.  

This fast and loose name-and-numbers philosophy mirrors T-SQL as in:

sp_adduser 'Figaro', 'Hero', 'Opera'

        could also be 

sp_adduser 'Figaro', @grpname = 'Opera', @name_in_db = 'Hero'

Don't know if we're on the same page yet.  HTH.  

and regards, 

--jkl

<quote>
SQLBindParameter

SQLBindParameter can eliminate the burden of data conversion when used to
provide data for the Microsoft® SQL Server(tm) ODBC driver, resulting in
significant performance gains for both the client and server components of
applications. Other benefits include reduced loss of precision when
inserting or updating approximate numeric data types.
[...]
When using the SQL Server ODBC driver version 3.7 or later, specify
SQL_PARAM_INPUT when binding input parameters. Only specify SQL_PARAM_OUTPUT
or SQL_PARAM_INPUT_OUTPUT when binding stored procedure parameters defined
with the OUTPUT keyword.
</quote>


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.