Skip to Content.
Sympa Menu

freetds - RE: [freetds] rpc better: now only broken

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] rpc better: now only broken
  • Date: Wed, 27 Nov 2002 16:07:01 -0500

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: November 27, 2002 2:18 AM

Frediano,

> Dynamic query on TDS5 (using TDS5_DYN_TOKEN) do not want named
> parameters.

TDS 5.0 defines an rpc protocol that does not rely on TDS5_DYN_TOKEN. For
TDS 5.0, I want to use TDS_DBRPC (E6), TDS_PARAMFMT (EC), and TDS_PARAMS
(D7). It looks pretty straightforward.

So far in TDS 7+ it looks like we don't know how to:

* pass named parameters
* read output parameter results from the server.

Is that right?

> Simply add a flags parameters to
> tds_put_data_info/tds_put_data_info_length to disable parameters name
> (or reset name in tds_submit_execute ??)

Named parameters are a requirement for normal db-lib operation.

> In TDSCOLINFO we have column_name and column_namelen... If column_name
> is NUL terminated column_namelen is just a duplicate information that
> can be out of sync...

That a philosophy issue. Mac OS X will (one day) pass us column_name in
UCS-2; we should not rely on strlen(), and we should anticipate that bufsize
!= namelen (especially for UTF-8!).

I don't know the right answer for TDSCOLINFO.

> Is our libtds that do not full support output parameters.

OK, do we support unnamed, positional output parameters?

> The patch I send fix the problem but my question still
> remain. When we read flags from db we split it on bit (like
> column_writable, column_nullable, etc). There are no flag for "this is
> an output parameters"...

Not sure I understand. What lines of code do you mean?

Even if there's no "output parameter" flag per se for us to read, the server
must send the data and communicate its purpose somehow.

> The patch store this information on
> column_flags... Another variable that duplicate informations and can
> became out of sync...

> Also what's
> the meaning of mixing named and unnamed?
> exec sp_test 1, @test = 'a', 2
> 2 is the second or third parameter ??

That's an invalid construction:

1> exec sp_columns @table_owner = 'dbo', systypes
2> go
Msg 119, Level 15, State 1, Server NTS0214, Line 1
Must pass parameter number 2 and subsequent parameters as '@name = value'.
After the form '@name = value' has been used, all subsequent parameters must
be passed in the form '@name = value'.

The db-lib behavior is the same.

Regards,

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






Archive powered by MHonArc 2.6.24.

Top of Page