FreeTDS Development Group

[Ken Seymour <kenaseymour AT yahoo.com>]

--- Brian Bruns <camber AT ais.org> wrote:
> Ken,
> 
> The TDS_PARAM_INFO structure is designed to handle
> 'output' stored 
> procedure parameters.  So it may not be what you are
> looking for.  The 
> patch looks good though. I'm not sure how that one
> slipped by, the 
> tds_free_param_results() function seems to treat it
> correctly...
> 
> ctlib also supports placeholder values, however I've
> never implemented 
> them.  You may want to check sybooks.sybase.com
> under the CT-Library manual 

I have the Sybase DOCS on CD (it came with server).

> for details on Sybases implementation. (ct_dynamic()
> and friends).  There 
> is protocol level support for it, however I doubt
> that MS SQL does it the 
> same way since it is a post-4.2 addition. I've never
> traced a prepared 
> statement to see way it looked like. BTW,
> DBD::Sybase would benefit from 
> placeholders as well.

At some point I will test from Perl.  I have used DBI
before.  It is just a question of having the time.

> 
> Just guessing, but the query is sent to the server
> with the TDS_LANG_TOKEN, 
> a size and 3 more bytes.  I imagine these probably
> flag prepared 
> statements, but that is just conjecture on my
> part...I'd need to do a trace 
> of the traffic to know for certain.  Again though,
> this would not work 
> under TDS 4.2 and probably works differently under
> TDS 7.0 (if at all).  
> So, a safe bet would probably be to implement it
> client side first then 
> optionally do protocol level implementations for TDS
> 5.0/7.0.
> 

I will plan to do the client implementation.  I am 
running both the client and server on RedHat Linux.
I have the Sybase server that came on the third CD
of an official RedHat 5.2 release.

The client implementation would provide compatibility,
at least, with other databases.  It would not provide
the performance increase that keeping the compiled
query provides.  But functionality is more crucial
than
performance.

I could add another field to the TDSSOCKET struct for
inbound params, or I can put it in the odbc structures
for now.  I think I prefer the latter until I have 
something.

At some point, maybe I can get another client (non
TDS)
using parameterized queries and watch the packets go
by.  We have SQLServer at work, but they will never
let
me hook up a Linux/Unix box or sniff the net in 
any way.  Besides, there is no "business need" for me
to do that.


> Brian
> 
> On 02/28/00, "Ken Seymour <kenaseymour AT yahoo.com>"
> wrote:
> > Brian,
> > 

Stuff deleted.

> ---
> You are currently subscribed to freetds as:
> kenaseymour AT yahoo.com
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
> 
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com