[fpc-pascal] Re: linux:
shouldwehard-codeversionedorunversioned shared libraries in our apps?
ludo.brands at free.fr
Thu Aug 16 11:59:52 CEST 2012
> Remains the fact that I think that - no matter what the other
> component sets do
> - the library name should NOT be a connection component
> property, unless you
> allow each connection to use a different library. Since that
> is not possible
> with the current *dyn units, the property should not be made
> at this level.
> What is then the solution ?
> If you look at AnyDac, you'll see that it is the only DB
> component set that IMHO
> does it correctly. It has a separate component for the
> library (the "physical link")
> of each type of connection.
> You drop this component on the form and set the library name
> (it has a reasonable default).
> Only one such component is needed for the whole application,
> no matter how much connections you make..
> Now, I happened to think that this may be a bit overkill,
> which is why I proposed
> a component editor popup to set the library, which can simply
> insert the correct
> statement in code.
> But if people want a point-and-click interface, we can always
> make a new component: TSQLDBLibraryLoader or so. With a
> property for the library name of each supported DB, so we
> need only 1 component.
I understand you prefer the perfect solution instead of the easy 3 line
solution most others have implemented and that appear to work very well for
them in 99% of the cases. I'm just afraid this quest for the perfect
solution will make that in 6-9 months nothing has changed and this same
discussion will pop up again.
More information about the fpc-pascal