> 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. Ludo _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
