[fpc-pascal] Re: linux: shouldwehard-codeversionedorunversioned shared libraries in our apps?

Ludo Brands 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 mailing list