Part of it Molly.
Was already afraid you was going to say that :-D
Databases are not my greatest virtue, and usually i set properties manually at runtime instead of design-time (so double my handicap
)
I tried to understand which relation TSQLDBLibraryloader has to TSQLConnector (TSQLConnection).
afaik, none whatsoever other then overriding some default behaviour (in particular the path and name of the library).
If the libraryloader is loading the clientlibrary, what is TSQLConnector (TSQLConnection) doing with the loaded library.
afaik the libraryloader is responsible for 'correcting' default behaviour that TSDQLConnection expresses. TSQLConnection and friends uses a default location (path) and name for the clientlibrary (.dll/.so) and this might not correspond to your (end-user)situation. Ergo Library loader let's you customize some (default) settings.
If this component is not available, TSQLConnector (TSQLConnection) handles the loading of the client library by itself (AFAIK).
afaik as well, yes.
Why is loading my project failing when I use TSQLDBLibraryloader.enabled := true.
No idea atm. The message you showed seem to indicate that the database/connection has already been opened ("database already loaded").
It's nice to know where you can find the procedures of the handled code, but is not my purpose.
Indeed it is not, but sometimes knowing the flow of the program is able to help you understand certain issues/topics. I assumed that is why you asked the question i quoted and replied to.
Delphi and Lazarus/FPC are built to build a application in the IDE without a single code put by user.
Although you as a developer do not have to code anything when visually creating a design, behind the scenes a lot of code is executed (either at design-time or at execution time) because of the (visual) changes that you've made.
All the properties you've changed are stored inside the .lfm file and when you load your program (either at execution or designtime) these changes are streamed inside your program and therefor a lot of those changed properties invoke code (that you probably never knew existed before).
That is why (under certain circumstances) it is advisable to build lazarus/components in debug-mode so that you are able to debug the components source-code at runtime and be able to see what the debugger has to tell.
Note that afaik using libraryloader requires you to set properties in a particular order, otherwise things might go amiss (see also
here). Did you follow the rules from that small example ? Also note that there are some libraryloader examples available in fpc source-tree.