[fpc-pascal] Re: linux: should
wehard-codeversionedorunversioned shared libraries in our apps?
ludo.brands at free.fr
Thu Aug 16 10:43:32 CEST 2012
> We differ only in the implementation of the 'easier way':
> I meant that I do not see the advantage of writing something like
> With Inifile do
> With IniFile do
Unfortunately your example illustrates nicely the difference.
InitializeInterbase is unknown in the fpc I'm using. InitialiseIBase60 does
exist but you have to add the non-trivial ibase60dyn to the uses clause to
get to it (Google has 146 hits for "InitialiseIBase60", non of the hits are
documentation or wiki pages). If it where a property of TIBConnection, non
of these difficulties would exist.
> Which is what you will end up writing in any real-world
> scenario. I have never seen a real project where the
> databasename set in
> the OI was the one actually used in the deployed app.
> I cannot remember when I've last used the OI for setting the
> username/password/databasename for a connection.
That is your usage case. The fact that username/password/databasename
properties exist in all db components I know of seems to suggest that there
are usage cases where it is used. I happen to use these properties
frequently for writing quick'n dirty (RAD) test programs or mock-ups or
during the development phase of a program. I hope that is still inside the
supported use of fpc?
> That, combined with the fact that the library name is project
> wide, lead me to the conclusion that there is no need in a
> property at the
> connection level.
> That said, if an easier way is needed to set the library name
> in the IDE, I'm all for it. I just don't think it should be a
> TSQLConnection property,
> for the reasons explained above.
Made a quick tour of the other dbcomponents I have on my system: Zeos
(TZConnection.LibraryLocation) , MDO (TMDODataBase.ClientLib), Delphi's
DBExpress (TSQLConnection.VendorLib). They have all this useless component
property to specify a project wide library. True, sqldb doesn't claim
compatibility with anything, so that shouldn't be a reason to do the same as
the others. But afaik the other components don't have the recurring
discussions on libraries not found or wrong library loaded, etc.
More information about the fpc-pascal