DLLLOAD errors indicate that one of the Connectivity Series components can’t load a needed DLL or shared library. The DLL or shared library may be missing, it may be invalid (incorrectly named or an incorrect version), its file specification may be missing from PATH (on Windows) or from the library path (on Unix), the listed DLL or shared library may not be able to access third-party DLLs or shared libraries it needs, or if you’re on Unix, the setuid (+s) bit may be set for the Synergy runtime (dbr). DLLLOAD errors occur only on machines that support either DLLs or shared libraries, and these errors are generally caused by a problem with the way Connectivity Series is installed or, on Unix, by a failure to source setsde correctly.
To troubleshoot these errors, run the dltest utility from the command line. This utility indicates whether needed Connectivity Series DLLs or shared libraries can be accessed. On Unix, it tells you the name of the library path environment variable (for example, LIBPATH on AIX). Note the following:
- Make sure all the resources that the DLL or shared library needs are available. For example, on Windows if you get a DLLLOAD error for GDS0.dll, it may be that Connectivity Series can’t find one of the DLLs required by GDS0.dll. (These include SDMS22.dll and VTXIPC.dll.) If you get a DLLLOAD error for one of the Synergy database drivers, such as vtx0_12.dll (a driver for Oracle on Windows), it may be that the target database isn’t set up correctly or that DLLs for the target database are inaccessible.
- On Windows, you can use the Dependency Walker utility (depends.exe) to determine which resources are required for a DLL. You can download Dependency Walker from www.dependencywalker.com.
- On most Unix systems, you can use the ldd command to determine which resources are required for a shared library.
- On Unix, make sure the setuid (+s) bit is not set for the Synergy runtime (dbr). The setuid bit prevents the library path environment variable from being used. This will cause DLLLOAD errors, though it won’t affect the ability of dltest to access needed .so files.
- On Unix, if dltest can access all the needed .so files (and the setuid bit is not the problem), there are a few possible causes:
- For SQL OpenNet, it may be that setsde isn’t sourced before vtxnetd attempts to implement the SQL OpenNet server. Check the rc file and make sure setsde is sourced before startnet.
- For an SQL Connection client application, it may be that setsde isn’t sourced for the process before the application is started. For example, if you run an SQL Connection application from a Unix processor, such as “cron” or “at”, be sure to source setsde from the shell script you use to execute your program. The setsde script must be sourced before the SQL Connection application.
- It may be that the target database isn’t set up correctly (in other words, that the database equivalent of setsde hasn’t been used) or that shared libraries for the target database are inaccessible. On most Unix systems, you can use the ldd command to determine which resources are required for a shared library.
For information on which Synergy shared libraries are causing the error, run dltest from the rc file (directly before the startnet command) or from the Unix command (“cron”, “at”, etc.) that runs the SQL Connection client application. Remember that the problem may be that Connectivity Series cannot access a third-party shared library needed by the shared library listed in the error (for example, clntsh.so may be inaccessible to VTX0.so when using Oracle).
