Discussion:
Michael: 0033917: TSQLQuery.CreateParams - override param class
(too old to reply)
Ondrej Pokorny
2018-06-28 08:45:22 UTC
Permalink
Raw Message
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

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m
Michael Van Canneyt
2018-06-28 09:32:07 UTC
Permalink
Raw Message
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.)

Ehm.
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.

Michael.
Luiz Americo Pereira Camara
2018-07-24 22:12:30 UTC
Permalink
Raw Message
Em qui, 28 de jun de 2018 às 05:45, Ondrej Pokorny <***@kluug.net>
escreveu:

> Therefore I wrote that I don't need #33918 and #33917 any more.
>

@Ondrej

Can you look at the comment of Michael Van Canneyt in
https://bugs.freepascal.org/view.php?id=33918 ?

About reverting the patch

Luiz
Loading...