[freetds] ct_param differences between 0.62 and 0.63
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Thu Jul 28 04:30:16 EDT 2005
>
> 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
More information about the FreeTDS
mailing list