When I try to "Test connection" it says: "A driver is not registered for the URL sdbc:postgresql:host=10.0.0.1 dbname=testdb" Extension manager shows installed PostgreSQL-SDBC Driver 0.8.2. When I choose "connect to an existing database", PostgreSQL is on the list.
Indeed.
On my Windows 7 32 bits system: Dependency walker from http://www.dependencywalker.com/ says two DLLs are missing: MSVCR90.dll (dependency of MSVCP90.DLL) IESHIMS.DLL (reverse dependency chain: IEFRAME.DLL / SHDOCVW.DLL / SHELL32.DLL) The second looks like a false positive: I doubt shell32.dll is broken on my system. The first is also weird: it is in the same directory where it found MSVCP90.DLL... Anyway, copying that file to the postgresql-sdbc directory does not solve the problem. I'll try to get a LibO/MS Windows expert to take a look.
At first I thought that it doesn't work because of libpq.dll, but I've tried to put 8.4 and 9.0 version with deps into postgresql-sdbc and it didn't help. I have MSVCP 2k8 redistributable package installed on this machine so I belive MSVCR90.dll is not a problem in my case aswell.
(In reply to comment #3) > At first I thought that it doesn't work because of libpq.dll In the official binaries distributed on http://www.libreoffice.org/, PostgreSQL-SDBC is linked statically against libpq, so libpq is inside postgresql-sdbc-impl.uno.dll
My wild guess is that the libldap*.dll is the cuprit. Did not look into the code, but most probable the extension manager looks for dependent libraries only in ure directory and not in the program directory. Maybe there would be a way to get this right. Stefan, do you have any idea?
(In reply to comment #5) > My wild guess is that the libldap*.dll is the cuprit. Did not look into the > code, but most probable the extension manager looks for dependent libraries > only in ure directory and not in the program directory. Ah, I had copied all libraries to the postgresql-sdbc directory, and when that did not work around the problem, I concluded that the dlls were not the problem, since I assumed they would be looked up for in the same directory as postgresql-sdbc-impl.uno.dll If you say that they are looked for only in the ure directory, that should be easy enough to check: if we copy them to the ure directory, then the symptom will go away.... No. I copied nsldap32v50.dll to "c:\progra~1\libreoffice 3.5\URE\bin", the symptom does not go away.
OK, the mozilla ldap stuff is linked against the Visual Studio 2005 runtime, so copying over the dll will not do it, since it will not find some of its dependent dlls. I think we have two options here: 1) refrain from supporting ldap authentication and retain the extension status of this driver 2) package this driver as integral part of LO (+/- easy solution) and retain all the LDAP related benefits. If there is a concensus about one of the options, I can go for it. Personally, I find the second one the sane option.
For a description how to test postgresql-sdbc, see <http://lists.freedesktop.org/archives/libreoffice/2012-January/024333.html> "rpath / ... for extensions (and the case of PostgreSQL-SDBC)."
My hope would be that the fix for bug 45090 improves the situation for this bug, too.
I can confirm that postgresql-sdbc is fixed in: libreoffice-3-5~2012-01-23_22.09.27_LibO-Dev_3.5.0rc1_Win_x86_install_en-US.msi Thank you very much for quick response!
(In reply to comment #10) > I can confirm that postgresql-sdbc is fixed in: > libreoffice-3-5~2012-01-23_22.09.27_LibO-Dev_3.5.0rc1_Win_x86_install_en-US.msi > Thank you very much for quick response! OK, marking bug as fixed then.