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.)
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. 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.
I took TDataSet.Translate into consideration as well but it has multiple problems:
1.) It doesn't really work well for UTF8<->ANSI conversions because the length can change and it doesn't really show what length is available in the buffer.
2.) It doesn't work for params.
Ondrej