Hi,

TSQLConnection.CharSet is defined as follows:

      property CharSet : string read FCharSet write FCharSet;

Currently you can pass parameters via the Params property, but they don't seem to be taken into account at all!! At least this is true for Interbase/Firebird connections. This is clearly not good.

A simple solution would be to use getter methods as follows:

      property CharSet : string read GetCharSet write FCharSet;

The GetCharSet method would then return FCharSet, but if it is empty, it must check the Params property for values. In the case of Interbase/Firebird that would be 'charset' or 'lc_ctype' in the Params value list. GetCharSet can be made virtual, so that other database backends (firebird, mysql, etc) can override it and to the extra tests and return possible values from Params property.

If this is ok, I will go ahead and make the change for CharSet property. Other properties will also benefit from this like: Username, Password, Role, DatabaseFilename, etc...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

This is not ok.

The fixed pre-defined properties should never be in the params list.

The descendents of TSQLConnection should take the contents of charset into account, and that's it.

There has been an exception for Port, but that is historically grown, and should not be repeated.

Michael.

2009/5/26 Michael Van Canneyt :

The fixed pre-defined properties should never be in the params list.

Why?? The following is perfectly legal in Delphi 7 and Kylix 3 using dbExpress components.

=========================
procedure TForm1.SQLConnectionBeforeConnect(Sender: TObject);
begin
  with Sender as TSQLConnection do
  begin
    if LoginPrompt = False then
    begin
      Params.Values['User_Name'] := 'SYSDBA';
      Params.Values['Password'] := Decrypt(Params.Values['Password']);
    end;
  end;
end;
=========================

What I am suggesting is simply that the dedicated properties Username, Password, Charset, etc. check it field variable first and if it's blank, then as a fallback it checks the Params values.

The descendents of TSQLConnection should take the contents of charset into account, and that's it.

For TSQLConnection, the GetCharSet getter method will simple return FCharSet field variable as a result. This means by default everything will work as is. Descendants of TSQLConnection can then extend GetCharSet by looking at Params values (only as a fallback, if TSQLConnection.GetCharSet returned an empty string.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

That's not a good reason: Delphi simply doesn't provide the username/password properties, so you are forced to use params.

But why would you duplicate information ?

Again: why would you want this ?

if there is a property charset, why for god's sake would you want to enter the same information again in the parameters ?

I don't mind you doing this, but I think it's a complete waste of time, and it encourages confusion...

Michael.

2009/5/26 Michael Van Canneyt :

That's not a good reason: Delphi simply doesn't provide the username/password properties, so you are forced to use params.

Fair enough observation. :)

It's not duplicating information, it's providing a fallback. Maybe the user did not specify a username and password via the dedicated properties because they are used to the way Delphi works or ported a Delphi project. Instead they used the Params property. The dedicated properties will take precedence and I'll update the docs to reflect that. Currently the developer would see a connection error, when in fact the information is there (in Params property), just not checked for.

The last two days i have spent a lot more time looking at the db components, and it seems the Params property is a lot of the time simply ignored.

if there is a property charset, why for god's sake would you want to enter the same information again in the parameters ?

Like I said above. Normally you would not duplicate the information. The checking of Params property is simply a fallback for information. Users might have ported Delphi apps to FPC and are used to the Params property.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Indeed, most things have a dedicated property for it. The params property was made to use in case there is no property.

And what will you do if someone sets the UserName property ? Write to the field, or will you also start checking params, and update that as well ?

IMHO We should enlighten them instead of encouraging them to stick to wrong habits :-)

What if 2 programmers work on the same project. programmer A fills in UserName, and programmer B checks Params.Values['user_name'] ? Should we cater for that ? It's confusing.

No, I don't think this is a good idea. I won't stop you, but I really think you're making a mistake.

Michael.

2009/5/26 Michael Van Canneyt :

And what will you do if someone sets the UserName property ? Write to the field, or will you also start checking params, and update that as well ?

As a safety precaution, it sets the value in Params as well. I think I saw something like this done in sqldb already (though I'm not sure - I looked at a lot of db code recently). The dedicated properties should always take precedence.

IMHO We should enlighten them instead of encouraging them to stick to wrong habits :-)

True. :)

What if 2 programmers work on the same project. programmer A fills in UserName, and programmer B checks Params.Values['user_name'] ? Should we cater for that ? It's confusing.

The solution I mentioned above will cover such a scenario and both programmers will get the same result.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/