FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il mer, 2002-11-27 alle 22:07, Lowden, James K ha scritto:
> > 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?  
> 

I'm quite tired.... I should reply tomorrow... however

No, I know how to pass named parameters and how to read results (already
implemented months ago, not by me...)

The confusion with TDS5_DYN_TOKEN came from tds_put_data_info. This
function is used in both tds5 dynamic and MS RPC. dynamic do not want
named parameters, so implementation do not use column_name (patch I sent
day ago send always the name). I applied a patch in query.c adding a
flag parameter to tds_put_data_info* and use it.

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

MM... very difficult... current implementation expect char as stored as
single-byte (no UCS-2, UTF-8), for example it expect that 2 UCS2
characters are converted to 2 byte and back... so for now column_namelen
is the length in byte (and of course length in characters).

> I don't know the right answer for TDSCOLINFO.  
> 

I'm expecting a reply from Bill on this...

> > Is our libtds that do not full support output parameters. 
> 
> OK, do we support unnamed, positional output parameters?  
> 

Same problem of TDSCOLINFO, simply how to store this flag...

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

In query.c 

        /* TODO store and use flags (output/use defaul null)*/
        tds_put_byte(tds,0x00); /* status (input) */

0x00 = input
0x01 = output
(also there are other bits)

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

If you don't mark "this parameter is output" the server do not reply
parameters, only status.

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

Now it's much more clear ! All unnamed are before named ones. This is
another check we should do in query.c.

freddy77