I'm flumoxed!

My app fails with the error "Cannot load Postgres Client. Is it installed? (libpg.dll)".

I've been developing my app on my laptop and initiallly was unable to get PQConnection working as it complained that Postgres was not installed.

I eventually loaded pgadmin3 onto my laptop, but the problem was only cured when I copied the ALL of the DLLs in the pgadmin install into my System32 folder.

I wasn't all that happy about it, but felt that I could live with having to copy 18 DLL files into the client's System32 directory.

However, the clients machines have all failed with the above error.

Copying the DLLs into system32 didn't help. And niether did installing pgadmin3, the error persists.

Does anyone have any idea why? Where does PQConnection expect to find the DLLs?

Better not copy he dlls, just add the postgres/bin dir to your path (mycomputer-properties-advanced-environmentvars).
(sometimes you need to restart the explorer to load your new envirenment)

did running pgadmin3 work ?

Does anyone have any idea why? Where does PQConnection expect to find the DLLs?

Like any other app as specified here:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Marc

Marc Weustink wrote

Better not copy he dlls, just add the postgres/bin dir to your path (mycomputer-properties-advanced-environmentvars). (sometimes you need to restart the explorer to load your new envirenment)

Yes, I tried that, but it didn't work.

did running pgadmin3 work ?

Yes it does.

Like any other app as specified here: http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Well, it says that the first place the dlls are searched for is in the application's own directory, but I have tried this without success.

Could it be that the path of reqired DLLs are hard-coded into PQConnection?

If that isn't the case, then it can only be that there is a dll missing, surely?

Pgadmin3 came with 18 DLLs all of which have been copied into the system32 directory, the executable's own directory and all paths to the DLLs have been added to the Path Environment variable.

And did you find the dll that was specified in the error message ? There are some issues with the exact naming: the names have changed over time. The library should be named exactly as in the error message.

Michael.

Maybe I'm missing a DLL. Here are the DLLs that came with pgadmin3.

comerr32.dll
gssapi32.dll
iconv.dll
k5sprt32.dll
krb5_32.dll
libeay32.dll
libiconv2.dll
libintl3.dll
libpq.dll
libxml2.dll
libxslt.dll
msvcm80.dll
msvcp80.dll
msvcr71.dll
msvcr80.dll
pgaevent.dll
ssleay32.dll
zlib1.dll

If I'm correct, the message mentioned libpg.dll ? Try renaming this dll.

Michael.

Hi!

18 dlls??

I had the same problem with PostgreSQL 8.2.5 in my developer PC. You only need to copy in System32 or other Directory

comerr32.dll
krb5_32.dll
libeay32.dll
libiconv-2.dll
libintl-2.dll
libpq.dll
ssleay32.dll

(I am not sure if dlls names are the same in your version)

If the Directory is not System32 needs Add it in your System PATH variable

I am sure it works.

Best regards,

Juan

I have only found these DLLs needed for a PostgreSQL client connection:

libpq.dll
libeay32.dll
libiconv-2.dll
libintl-2.dll
comerr32.dll
krb5_32.dll
ssleay32.dll

The client program only accesses libpq.dll directly, but libpq appears to use the other DLLs listed above.

There is no hard-coded path in libpq, I haven't seen anything such short-sightedness on the part of the PostgreSQL develpment team. They have done excellent work, and both PostgreSQL and libpq are documented quite well in html.

From your other messages it appears you are still using Lazarus db components, which is fine. In this case the FPC/Lazarus team has already done the interfacing to libpq for you.

But you still need libpq.dll and supporting DLLs above.

Windows will search for a requested DLL first in the current folder, then folders in the search PATH. Nothing new here, and nothing special for libpq.

Also, for the record, installing a Verifone application called "PC Charge" can throw your PostgreSQL client because Verifone decided to name one of their DLLs libpq.dll and put in in the windows system folder (idiotic in this day) along with a slew of other DLLs to add to the mess.

I'm glad to see you found the circular reference in your query component.

Be persistent and work it out.

2008/5/29 Jalal :

There is no hard-coded path in libpq, I haven't seen anything such short-sightedness on the part of the PostgreSQL develpment team. They have done excellent work, and both PostgreSQL and libpq are documented quite well in html.

Jalal, your input has definitely assisted my project and for this I'm very grateful.
I hope I'm not accusing anyone of shortsightedness.

Also, for the record, installing a Verifone application called "PC Charge" can throw your PostgreSQL client because Verifone decided to name one of their DLLs libpq.dll and put in in the windows system folder (idiotic in this day) along with a slew of other DLLs to add to the mess.

The client machines are 'out of the box' and have no other software installed.

I'm glad to see you found the circular reference in your query component.

I was really confused about that. I didin't think that there were any circular references, but removing the Tdatasource component, as you suggested certainly made it work.

Be persistent and work it out.

Unfortunately I have very little time; my principals are due to place the order for the proprietary software tomorrow morning....

Op donderdag 29-05-2008 om 22:24 uur [tijdzone +0200], schreef Dave Coventry:

You didn't mix up 64-bit and 32-bit dlls accidentally?

Joost

Dave,

My comments were to assure you that libpq and PostgreSQL work well. There is simply a learning curve for something new. I faced a curve when I jumped into Lazarus (from Delphi) and PostgreSQL (from MSSQL), and I still use all of the above.

I am not a developer of any of the products discussed here.

I mentioned PC Charge only as a general FYI for anyone interested.

There have been times when we lost a customer because there was something they wanted that we could not produce in time for their schedule.

Joost van der Sluis wrote

You didn't mix up 64-bit and 32-bit dlls accidentally?

Well I installed pgadmin3 on the machine and it runs.

I copied ALL 18 dlls from the C:\Program Files\pgadminIII\ Directory into System32\ and, when I start my app it generates an error message asking for libpg.dll.

Try to copy the libraries in the directory of your application.

The procedure to load the library uses a straight windows loadLibrary call, as can be seen from the following:

Procedure InitialiseDllist;
begin
  inc(RefCount);
  if RefCount = 1 then
    begin
    DllistLibraryHandle := loadlibrary(pqlib);
    if DllistLibraryHandle = nilhandle then
      begin
      RefCount := 0;
      Raise EInOutError.Create('Can not load PosgreSQL client. Is it installed? ('+pqlib+')');
      end;

So normally it should find it.

Michael.

I don't know what more I can try.

It doesn't make sense.

Why should the laptop be able to run when the DLLs are copied to the system32 directory, yet the Desktop clients are generating an error message which says that the Postgres Client is not installed (libpq.dll).

Could it be that the error message is misleading? Might it be something else which is tripping up the app?

I have not followed your thread, just a simple idea: maybe there is a full path reference somewhere (Registry, cfg or ini files, ...) to some of the required files.

- Leslie -

Of these, libiconv-2.dll is on neither my laptop, nor the client desktops, however, libiconv.dll is on both, typo?

libintl-2.dll is not on the Desktop client, but it IS on my laptop as part of Inkscape. However, copying it to the Desktop does not help.

libintl3.dll, is present, as part of the pgadmin3 installation listed below.

Of these, libiconv-2.dll is on neither my laptop, nor the client desktops, however, libiconv.dll is on both, typo?

Sorry, my turn to produce a typo, I meant, of course, libiconv2.dll

Why should the laptop be able to run when the DLLs are copied to the system32 directory, yet the Desktop clients are generating an error message which says that the Postgres Client is not installed (libpq.dll).

The load can fail if libpg.dll or one of the dlls it uses does not exist on the PC. Try opening libpg.dll with http://www.dependencywalker.com/ and check that all the dlls it lists exist on the PC

Greetings
S?ren

Soren, for a moment there I thought the Dependency Walker was the answer to my problems, but it appears that it is a snare and a delusion.

It lists different DLLs as being missing on the working system and on the borked system.

Some of the DLLs which are listed as present are not in either system.

MSJAVA.DLL, for example is listed as present on the working system, but missing on the borked system, when it is present in niether.

Nowhere is libpq.dll (or any of the other DLLs mentioned on this thread) listed by Dependancy Walker on either system.

Is there a more reliable way of working out which DLLs are required by the program?

I have wasted 2 days (and almost 2 nights) trying to figure out what is going on and am very close to giving up entirely.

If it is about the FPC program: no. The program loads the library dynamically. The best you can do is list the dependencies of libpq.dll, and make sure these are present on both systems.

Michael.

Do you know that page?:

http://www.postgresql.org/docs/8.2/interactive/install-win32.html

On other systems there may be a client-only-package (FreeBSD and Debian at least).

HTH,
Marc

Michael, Marc, Soren, Jalal, Joost et al,

Thanks very much for your assistance.

I ran Dependency Walker on the libpq.dll and found there was some kind of error on the file, so I deleted all instances of libpq.dll on the system (I had ended up with 4 or 5 copies of the file with all my experimentation) except the ones in the pgadminIII directory.

I added the pgadminIII directory to the PATH environment variable, and ....

...It wotks!

Without wanting to sound churlish, I am a bit of a loss to understand why the PQconnection needs to use the libpq.dll in the first place. I'm sure a lot of the Queries could be handled by communicating directly with the psql command line through ssh.

You could try to do this;
But it would be horribly inefficient, making it totally unusable.

The recommended programmer's interface is libpq.dll, so that is what we use. The problems you experienced are what is known as DLL hell, and occur under many circumstances, not just with PostGreSQL.

Michael.

Yes, DLL hell it is.

That's why I was dismayed to see that PQconnection used the DLL (and not just one, it uses several).

But I suppose if there's a good reason for it....

All database interfaces always should use a DLL.
That's what they are for, after all.

Alas, theory and practice are not always on par :-)

Michael.

Most databases do it that way, e.g. Firebird and MySQL do have a client side installation relying on a dll/so, too.

The library is the communication stub on the client side. Inside there is the implementation of the communication protocoll which is mostly unique for each sql server.

If the communication was done using the command line this would involve a shell, the utility program and ssh/ssl. Looking at ssh would be using what? A library implementing the communication protocoll on the client side ... but one had to deal with moving query and result to and from a TProcess or something. How would you do that when multiple result were to transfer from the server? What if the variable $LANG was set by the user? Do the lines transferrred as text end on #10, #13 or #10 + #13? How would error codes from the server or the connection shell would be differentiated from each other and handled?

Having a library eliminating a lot of such problems and encapsulating the rest is not that bad. It costs you having to care for one thing: the client computer has to have the correct dll/so or client package installed that fits the server version in use.

Regards,
Marc

Le May 31, 2008 ? 1:31 PM, Dave Coventry a ?crit :

Yes you can update it (security vulnerabilities for example) without updating the whole app.
It is important for big apps.

wrote:

[snip]

Without wanting to sound churlish, I am a bit of a loss to understand why the PQconnection needs to use the libpq.dll in the first place. I'm sure a lot of the Queries could be handled by communicating directly with the psql command line through ssh.

Besides other disadvantages.... a windows machine hasn't ssh either, so those exe/dlls need to be installed too. So you still need some installation.

Marc

Telnet?