LogSql()

[antoineL]

Hi!

I guess from the comments that the TGDbConnectionBase is somewhat a newcomer, and that it was created from TGDbConnection.
While doing so, the LogSql() method was left within TGDbConnection, guarded with {$IFDEF SQLDEBUG}.
Meanwhile, within the ExecSqlRaise() method, there is a call to that LogSql() method.

Since now ExecSqlRaise() is declared as a method of TGDbConnectionBase, the people which are still reading me at this point have certainly connected the dots and know that as soon as ones DEFINEs SQLDEBUG, the compiler yells.

So I believe LogSql() should be available as a method of TGDbConnectionBase, and hence code should lifted from one unit to the other.

Preliminary test here does not show any problem.

BTW, I found that more information can be obtained by using a TZSQLMonitor component; much much more information.
Is it because the latter is so verbose that this LogSql() feature was put in place?

[tintinux]

Hi

You are right on all points !

I have forgotten to move LogSql when GDbConnectionBase was created (in Gestinux 1.5).
It should belong to this unit, also to be used in non interactive projects not using GDbConnection (the reason for the split).
However as long as the condition was not activated, the error was not visible.

About the TZSqlMonitor, yes, I find it a bit too verbose. But this can be discussed...

Regards

[antoineL]

I was trying to move the LogSql() feature where it belongs.
While trying it, I noticed two things:

• One is that the code (recently added) which shows a message box to warn the user of the creation of the SqlDebug.log in $HOME, can't be used as if in gdbconnectionbase.pas, since it is supposed that this latter unit should not invoke GUI features.
  The "usual" solution would be to override the invoked method in gdbconnection.pas to have the Show there. Since it only makes sense on creation, I would use a second method instead, or perhaps send an event in gdbconnectionbase.pas and optionally catch it somewhere else as seems fit. But then I do not feel comfortable having such code depending on $IFDEFs...
• The mechanism to activate the SQLDEBUG feature is awkward: one has to go to the semi-hidden gestinux-base package, change its custom options (to define the symbol), clean and recompile that package, then recompile the application (I do not master Lazarus, so perhaps I am wrong; but that description matches my experience)

My current idea would be to have some sort of activation mechanism which could be seen through a design property, which could be the name of a local file, something which would solve the need to advert the ubication of the newly-created file. That way, if the programmer wants debugging, she just changes that property in the Db component del DataModule. Even if it is also permanent, it does not have overhead when the property is not set (normal case). The only problem is a potential security backdoor this could create (very small problem I believe.)

Then, if Logging is enabled in gdbconnectionbase.pas, the handler in LogSql() would log it only if the property is set.
Alternatively, if the property is the filename, when the property is not set, it could log to some determinate place, like $HOME/SqlDebug.log (the first option then would be as if the default value of the property is effectively /dev/null.)

We could make the logging code itself, that is the LogSql() method, permanent in gdbconnectionbase.pas (I do not believe the added weight is important, but I could be wrong, since it brings in the System.TextFile I/O stuff). It would allow anyone to use that mechanism independently of the setting of the SQLDEBUG $IFDEF in the gestinux-base package.

What do you feel about it?

[tintinux]

Hi

IMHO, the activation by a compilation directive is the good and usual way for such a thing.
A log is needed only during developement, and only by some developer during a limited time and scope.
So the $IFDEF looks well designed for that.
It would not be good to activate it by a property of the component, because it should not be saved with the project.

But you are right, the messagebox prevents to move the method in GDbConnectionBase.

Of course it could be possible to add a event in the component to trigger the messagebox.
But, as I said above, this shoul be activated only if the compiler directive is defined.
I don't think it's worth it, and supressing the messagebox is simpler, since it is not very useful !

In a server or console program with no GUI, the writeln should work fine, so it should be possible to move SqlLog to GDbConnectionBase.

Best regards