[fpc-devel] Michael: 0033917: TSQLQuery.CreateParams - override param class

Michael Van Canneyt michael at freepascal.org
Thu Jun 28 11:32:07 CEST 2018

On Thu, 28 Jun 2018, Ondrej Pokorny wrote:

> Hello Michael,
> because I cannot comment on resolved issues without reopening/closing 
> them, I'd like to send the question here.
> Issue reports: https://bugs.freepascal.org/view.php?id=33917 and 
> https://bugs.freepascal.org/view.php?id=33918
> I see you applied #33918 but #33918 doesn't make really much sense 
> without #33917. AFAICS I cannot define a custom TParams class for a 
> TSQLQuery. See:
> TCustomSQLQuery.Create(AOwner : TComponent);
> Var
>   F : TQuerySQLStatement;
> begin
>   inherited Create(AOwner);
>   F:=TQuerySQLStatement.Create(Self); << hard-coded TQuerySQLStatement 
> here - I need to tell TQuerySQLStatement what Params it has to create.
> (Put a breakpoint into TParams.Create to see the call stack.)

Your bugtitle is somewhat misleading then. I didn't check the diff after reading it:
With the comment you wrote I thought it resolved.

"Cannot customize created TSQLQueryStatement" or so would have been better.
I applied the patch anyway, see below.

> So if you decided to apply #33918, #33917 should be applied as well. Or 
> revert #33918 - it cannot be (easily) used without #33917 anyway.
> ---
> Background of my problem (no important information, skip if not interested):
> I need to read/write data from a 3rd party PHP eshop that uses MySQL and 
> that stores strings as UTF-8 double-encoded into ANSI. E.g. the 
> character "é" is stored as "é" (the codepage in MySQL is ANSI but UTF-8 
> is stored there as bytestring) - yes, this is very wrong but I cannot do 
> anything with it.

I feel your pain... Php and MySQL can produce the weirdest data.

> Therefore I need to reencode every input and output 
> into the DB. First I overrode TParam and TField methods but then I 
> decided to do this conversion within TMySQL55Connection, which is more 
> generic. Therefore I wrote that I don't need #33918 and #33917 any more.

All clear now.

Nonetheless, the patch is indeed useful in it's own right, I have
applied it and added some changes that should allow for more customization.
Allow you to control the class of TCustomSQLstatement that is used, and 
the connection will now use the same class as the original Query when
creating update/insert/delete statements.

Please check and close if OK.


More information about the fpc-devel mailing list