FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> Thanks Freddy,
> 
> > tds_build_param_def_from_query and 
> tds_build_param_def_from_params are
> > too similar, is better to reuse code. 
> 
> You're possibly right. Common, reusable code is obviously a 
> good thing,
> but sometimes it can make the resulting code more difficult to
> understand/maintain.
> 
> > tds_submit_query_params was used only by ctlib so there is 
> no reason 
> > for a tds_submit_query_params_ct
> 
> I didn't realise that. good spot.
> 

Fixed, deleted tds_submit_query_params, renamed
tds_submit_query_params_ct to tds_submit_query_params

> > also IMO tds_submit_query_params_ct should
> > support named and no named parameters (even using TDS7)
> 
> I didn't fancy writing a SQL parser, which AFAICT is the only way 
> to achieve this.
> 

Yes, a parser is required. I discovered that is required even to support
'?' style parameter under Sybase... Even mssl support @param style on
server so I think that is better to rewrite code in another way, I would
suggest

- are there '?' style parameters? Substitute '?' with @Px (where x is 1,
2, 3, ...) and use these names for parameters. Do not use names passed
(do give error if names used ?? do use these names instead of @Px ??)
- if some parameters are unnamed parse query and try to detect missing
names. Is an error to use a mix of named and unnamed parameters??
- use query literally and parameters too

query sustitution should be done in client charset. Only on prepare use
default parameter type (varchar(80)). Also tds_submit_execdirect do not
support parameters for tds5, perhaps is better to use language
parameters instead of emulated execute (see coverage of
tds_submit_execdirect at
http://freetds.sourceforge.net/coverage/tds/query.c.gcov.html)...

bye
  freddy77