[fpc-devel] TSQLConnection.CharSet improvement suggestion

[Michael Van Canneyt]

On Tue, 26 May 2009, Graeme Geldenhuys wrote:

> 2009/5/26 Michael Van Canneyt <michael at freepascal.org>:
>>
>> 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. :)
>
>
>>> 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.
>>
>> But why would you duplicate information ?
>
> 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.

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 ?


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

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.