This function is currently only implemented in Windows builds of IBPP. It is a no-op on other platforms. It allows the host application to better control which instance of fbclient.dll will get loaded and used by IBPP if there exists the possibility of multiple copies of fbclient.dll on the machine.
By default, IBPP attempts to load the Firebird client library in the following order:
DefaultInstance
registry value of the SOFTWARE\Firebird Project\Firebird Server\Instances
registry key,
By calling ClientLibSearchPaths()
before any other IBPP API is called, the host program can submit a list of semi-colon separated paths from which IBPP will try, first, to find and load fbclient.dll.
ClientLibSearchPath("My\\Specific\\Application\\Path;Somewhere\\Else"); ...
If no instance of fbclient.dll can be loaded from those additional paths, then IBPP will simply silently default to its above search order.
It should be noted that before attempting loads from locations specified by ClientLibSearchPaths
or by the steps 1. to 3. above, IBPP will first add the attempted directory in the front of the PATH value (in the process environment). This step helps the system find the dependencies of fbclient.dll in the same directory as fbclient.dll itself. This means that if you want to load a specific copy of fbclient.dll from some private directory of your application, you should have the binary dependencies of fbclient.dll (the C/C++ runtime Microsoft DDLs) located in that same directory. This is obviously not a requirement, if you know that those runtime libraries are available in the system directories.