2018-06-28 08:45:22 UTC
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
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
TCustomSQLQuery.Create(AOwner : TComponent);
F : TQuerySQLStatement;
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
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
2.) It doesn't work for params.
fpc-devel maillist - firstname.lastname@example.org