windows 7 64 bit postgres can't find libpq.dll error

[jacem]

When I try to connect I get the error

can not load postgresql client. Is it Installed? (libpq.dll)

I've read many off the discussions on this error and have the following questions

1> Can you connect to a PostgreSQL server from a machine that does not have PostgreSQL or pqAdmin III installed on it?  The main server of course does but installing a database server on every laptop and and customer service machine seems a little odd.

2> Is this error arch specific.  Win32 verse Win64.  I first started with the 64 bit version of lazarus only to find that only the MySQL5.0 and ODBC connectors were compilable   How compatible is SQLDlas with 64 bit systems?

Thanks in Advance

Jonathan

[BigChimp]

Jonathan,

1. (At least with mysql and sqlite it works like this): what about copying a valid PostgreSQL driver (presumably containing libpq.dll), e.g. into the application directory (or installing the driver using an installer or whatever into the system directory).
Does it work then?

2. You cannot use a 32 bit DLL in a 64 bit application, so you would need a 64 bit libpq.dll. Strange that you only see MySQL 5 and ODBC; at least the Firebird driver should be there as well.

[jacem]

I'm pretty sure firebird was there I no longer have 64bit lazarus running anywhere to check.  The list was very limited and no trick I could think of could expand it.

You mentioned 32 bit dlls not working in the 64 bit world but will 64 bit dlls work in 32 bit land?

Thanks

Jonathan

[BigChimp]

No, 64 bit DLLs won't work in a 32 bit environment.

Did you get your problem solved?

[jacem]

I have the 64 bit version of postgres running and TpqConnect does not show up in the 64 bit version of lazarus.  The postgres manual says that current versions are natively 64 bit in a way that suggests to me at least that 32 bit versions will soon be depreciated.

Is there a way to get the 64 bit version of lazarus to compile the sqlite3, MySQL 4 and 4.x and postgres connectors?

Also I'm trying to write a stand alone client that will access a postgres server remotely, so the real question is will the compiled app (final deliverable) need to be on a host with some form of postgres installed. 

As some of the hosts are running on 32 bit machines, will there be a problem with connecting a 32 bit client to a 64 bit server.

Jonathan

[BigChimp]

Is there a way to get the 64 bit version of lazarus to compile the sqlite3, MySQL 4 and 4.x and postgres connectors?

Don't know, haven't tried. Try downloading a 64 bit snapshot and see what is there. If they're not there, and you hit errors on compiling them yourself, I'd suggest opening bugs in the bugtracker.
The people who look at the bugtracker (*cough* FPC/Lazarus developers *cough*) might not look at each and every forum post...

Also I'm trying to write a stand alone client that will access a postgres server remotely, so the real question is will the compiled app (final deliverable) need to be on a host with some form of postgres installed. 

If you want to use a PostgreSQL database, you have to run it on a host. That host can very well be the local machine where your application runs, or it can be a server across the world. You just need to have access to the port it's listening on, valid credentials, etc.

As some of the hosts are running on 32 bit machines, will there be a problem with connecting a 32 bit client to a 64 bit server.

I wouldn't think so: both would implement the protocol PostgreSQL expects across the network (even if it is through the loopback adapter on the local host).
To be sure, you'd have to ask somebody who has more experience with PostgreSQL or read their documentation *hint*...

HTH,
BigChimp

[jacem]

I have 2 windows 7 premium boxes and a windows 7 professional box, in the 64bit version of lazarus none of them had the postgres or sqlite3 or either of the mysql 4.x connectors.  I could figure out no way to get the connectors to compile.  Removing the checks from the make files either crashed or failed the compilations.  Switching to the 32bit version of lazarus provided all of these connectors _quote out of box _unquote.

Attempting to compile the sqlie3laz.lpk also failed in the 64bit version, on one of premium boxes and the pro box (I made no attempt to compile it on the other premium box.)

Gentoo linux has had the lazarus package masked on the amd64 keyword for quite a few years now. whether I attempt the unmasking process depends on several factors including how apps developed in lazarus deploy.  The server will finally be deployed on a 64 bit gentoo server.  The host has 16 gigs of memory so down grading to 32bit is not an option.  The clients are a mix of 64 and 32 bit windows boxes with possibly a sabayon box or two in the mix.

In java, perl, php, and c/c++ the target database server software does not have to be installed on the client host, it only has to be installed on the server host.

Java needs the right jdbc connector either in the right place in the path, or with the eclipse big jar option essentially static linked.  Perl does need the DBI and DBD components.  In c/c++ static or dynamic linking are options.  With, PHP to be honest it's been a while.

Several forum replies on this forum suggest that in order to develop for postgres the postgres server software or at lest pqAdmin has to be installed on the developers machine, (not on a server host reachable by network but on the actual box the developer is sitting at.) I am wondering if I can get clarification on that issue?

I would also like to find out if the host running applications that are developed in pascal/lazarus as postgres dataclients are going to need to have the postgres server software installed on them as well? 

thanks in advance

jonathan

[BigChimp]

Hi Jonathan,

I have 2 windows 7 premium boxes and a windows 7 professional box, in the 64bit version of lazarus none of them had the postgres or sqlite3 or either of the mysql 4.x connectors.  I could figure out no way to get the connectors to compile.  Removing the checks from the make files either crashed or failed the compilations.  Switching to the 32bit version of lazarus provided all of these connectors _quote out of box _unquote.

Attempting to compile the sqlie3laz.lpk also failed in the 64bit version, on one of premium boxes and the pro box (I made no attempt to compile it on the other premium box.)

Very good that you tried to compile the components. It sucks that it didn't work. Strange that you'd try it on multiple machines with 64 bit Windows, but ok. As I mentioned before, I'd suggest:

If they're not there, and you hit errors on compiling them yourself, I'd suggest opening bugs in the bugtracker.
The people who look at the bugtracker (*cough* FPC/Lazarus developers *cough*) might not look at each and every forum post...

Gentoo linux has had the lazarus package masked on the amd64 keyword for quite a few years now. whether I attempt the unmasking process depends on several factors including how apps developed in lazarus deploy.  The server will finally be deployed on a 64 bit gentoo server.  The host has 16 gigs of memory so down grading to 32bit is not an option.  The clients are a mix of 64 and 32 bit windows boxes with possibly a sabayon box or two in the mix.

Don't know Gentoo and masking, or what that has to do with deploying apps. Does gentoo block Lazarus/FreePascal applications on 64 bit? That would be weird.
If the masking stuff means Gentoo doesn't allow you to run the Lazarus IDE, it might be best to develop an a 64 bit Linux that does support Lazarus, possibly in a virtual machine. Please see the snapshots/download page for a list of easy environments to run Lazarus on.
Maybe the postgresql connector will be there, as well. Somebody with more PostgreSQL experience can probably answer that.
There's also the wiki page at
http://wiki.lazarus.freepascal.org/postgres
Don't know if that helps.

In java, perl, php, and c/c++ the target database server software does not have to be installed on the client host, it only has to be installed on the server host.

I would imagine the same applies to Lazarus. IIRC, I played with a Postgresql application a long time ago (Windows client, separate Linux database server), don't remember any problems. Did I tell you you had to run a server on your client machine? No, I told you it is an option if you have no separate database server.

Several forum replies on this forum suggest that in order to develop for postgres the postgres server software or at lest pqAdmin has to be installed on the developers machine, (not on a server host reachable by network but on the actual box the developer is sitting at.) I am wondering if I can get clarification on that issue?

Did this work? Have you tried it? I imagine that would be clarification enough:

1. (At least with mysql and sqlite it works like this): what about copying a valid PostgreSQL driver (presumably containing libpq.dll), e.g. into the application directory (or installing the driver using an installer or whatever into the system directory).
Does it work then?

I would also like to find out if the host running applications that are developed in pascal/lazarus as postgres dataclients are going to need to have the postgres server software installed on them as well? 

Now you have me confused. Earlier you described a scenario with a separate PostgreSQL server and various machines that have a Lazarus client program talking to that database.
What do you mean by this part?

[jacem]

If they're not there, and you hit errors on compiling them yourself, I'd suggest opening bugs in the bugtracker.
The people who look at the bugtracker (*cough* FPC/Lazarus developers *cough*) might not look at each and every forum post...

I am attempting to determine if the problem I am having is in fact a bug and not operator error before making a bug report.

I would imagine the same applies to Lazarus. IIRC, I played with a Postgresql application a long time ago (Windows client, separate Linux database server), don't remember any problems. Did I tell you you had to run a server on your client machine? No, I told you it is an option if you have no separate database server.

If the same applied to lazarus and postgres then installing the SQLdb package would be all that would be required.

In the research I have done on the lazarus forums and the wiki several posters suggested that in order to get around this error and the related libpq.so error on the linux side you had to install the server on the development machine, not simply have it installed on a net reachable server, but on the machine that lazarus is running on.   So you can not only put an entry in the path, but copy the dll to the application.  (The precise meaning of application is not specified.)  Unceremoniously copying dlls around strikes me as a bad idea both from personal experience and from the large number of posters who have stated that copying dlls around was a bad idea.

If a small set of DLLs do have be included with the distribution of the client, not an unheard of situation, then the list of these and a method of generation have to be clarified.

Jonathan

[BigChimp]

I am attempting to determine if the problem I am having is in fact a bug and not operator error before making a bug report.

Fair enough. You might want to post the actual errors you're getting and which guide/tutorial/readme you were using when compiling the units.
Also, if you get no answer here, the fpc and lazarus mailing lists have a lot of traffic and people there might be able to help you.

I would imagine the same applies to Lazarus. IIRC, I played with a Postgresql application a long time ago (Windows client, separate Linux database server), don't remember any problems. Did I tell you you had to run a server on your client machine? No, I told you it is an option if you have no separate database server.

If the same applied to lazarus and postgres then installing the SQLdb package would be all that would be required.

In the research I have done on the lazarus forums and the wiki several posters suggested that in order to get around this error and the related libpq.so error on the linux side you had to install the server on the development machine, not simply have it installed on a net reachable server, but on the machine that lazarus is running on.   So you can not only put an entry in the path, but copy the dll to the application.  (The precise meaning of application is not specified.)  Unceremoniously copying dlls around strikes me as a bad idea both from personal experience and from the large number of posters who have stated that copying dlls around was a bad idea.

If a small set of DLLs do have be included with the distribution of the client, not an unheard of situation, then the list of these and a method of generation have to be clarified.

Jonathan

"The precise meaning of application is not specified": IIRC, Windows searches for DLLs in a couple of places, e.g. in your path, which should include the System directory (typically c:\windows\system32\), and finally in the "current" directory the application is running in.

When someone tells you to copy dlls, I would indeed be as cautious as you are: don't just copy them to the system directory overwriting other versions, as other software may now fail if they rely on specific versions of dlls.
You can, however, safely (well, if the dlls themselves are not infected with viruses etc) copy dlls to the directory where your compiled application resides in.

3 scenarios:
1. You need to have just SQLDB installed and nothing else. This works for dbf support, as that is built in into FreePascal.
2. You need to have just SQLDB installed and some kind of server somewhere. This works for e.g. the MySQL and Firebird/Interbase FreePascal units are translations of the C client files, speak the wire protocol without any additional help, and can therefore function without any dlls/shared libraries.
3. You need to have SQLDB installed, and some kind of dll that SQLDB calls for your database driver. This also applies to embedded databases such as SQLite and Firebird embedded, as their embedded engine is provided by a dll.

I still think situation 3 applies so you would just need to copy the Postgresql client dll only, plus required components. (Why would you need server components if you only have to speak the wire protocol over the network - for which the client dll is meant?)
Have a look here:
http://paginas.fe.up.pt/~asousa/wiki/doku.php?id=proj:lazarus_projects#easy_db
It apparently includes kerberos, xml and other libraries that might not be necessary.
I'd suggest trying to strip out everything except libpq.dll and see if it still works..

Does that application compile and run for you?

I do agree that the required dlls need to be documented, e.g in
http://wiki.lazarus.freepascal.org/Lazarus_Database_Tutorial#Lazarus_and_PostgreSQL
... but the PostgreSQL documentation is very thorough and probably specifies exactly what dlls are needed for client applications.

HTH,
BigChimp

[BigChimp]

The server will finally be deployed on a 64 bit gentoo server.  The host has 16 gigs of memory so down grading to 32bit is not an option.  The clients are a mix of 64 and 32 bit windows boxes with possibly a sabayon box or two in the mix.

Jonathan,

Thinking about your problems your quote above hit me.

Will you be deploying a 64 bit postgresql server on the Gentoo machine, and will your Lazarus clients (on the other machines, or possibly also on the Gentoo box) talk with Postgresql directly (e.g. no Lazarus/FreePascal app in between)?
Depending on how efficient you program (e.g. the amount of data you transfer over the wire=>efficient use of WHERE statements in queries etc), you might very well be able to just compile your application for 32 bit Linux and Windows without any noticeable performance problems.
This way, you'll still enjoy the performance of the PostgreSQL environment, but you don't need the hassle of fighting with 64 bit FCL-DB code...

HTH,
BigChimp

[jacem]

The lazarus application that I am contemplating will be a client that talks to postgres server directly, there should not be anything in the middle.  That's the point of the app; data entry and report generating front end to an sql back end.  Postgres was chosen because MySQL is not compatible between minor releases that is why there are 3+ mySQL connectors and the current stable release of mysql is not supported by the current stable release of FPC, at least 2.5.x is not a one click installer option.

The server will be a 64 bit server because postgres runs natively on 64 bit and the machine has all that memory why not use it.  As for the client machines some of these will be 64 bit and some will be 32 because of hardware.  As long as intel keeps shipping 32 atom chips I'm confident that 64 bit windows will have backwards compatibility.  Cross compiling the 32 bit version from the 64 bit code base was a problem I was waiting to address, or simply ignore by simply developing the win client as 32 only.  Some 64 bit Linux distros are pure ( they will only run 64 bit apps,) but that is also in the future, and macs are not cheep.

Now to go back to your post before this post. 

IIRC once the networking has been turned on you should be able to send queries to postgres through port 5432 from a raw telnet connection, once authentication has been done.   I have not been able to verify this because of the usual windows firewall nightmare.  So I am not sure what libpq.dll would even do other than generate an md5 hash of the password.  So it may be like MySQL and Sendmail in that getting kicked out by the authenticator is a good test to see if you can really connect.  So it should very much be scenario 2 and not scenario 3.

{whine}As for the copious quantity of postgtes documentation most of it is about non standard SQL functions and there is remarkably little documentation on administration or installation.{/whine}

Easy_db gives the same error but the problem could be a version mismatch with 32 bit lazarus and 64 bit ;ibpq.dll.  easy_db does not document whether is is using the 64 or 32 bit version of lazarus.  one more reason not copy dlls around in informal ways

TIA

jonathan

[BigChimp]

Sorry Jonathan, but I'm giving up.

Now you say can't access your PostgreSQL server from your clients due to "the windows firewall nightmare". Shouldn't be possible, windows firewall doesn't block outcoming and resulting return connections.
Can you connect with your linux boxes then?

Hint: pg_hba.conf in postgresql, enable network access...

Maybe other people can help you further...

Good luck,
BigChimp

[jacem]

Now you say can't access your PostgreSQL server from your clients due to "the windows firewall nightmare". Shouldn't be possible, windows firewall doesn't block outcoming and resulting return connections.

Windows firewall does have outbound rules.  So like opera web browser my win 7 pro laptop felt that pqAdmin was not secure for use on private, home and work nets but fine for public connections, unlike Firefox which it feels should only run on private nets and not in internet cafes.  This is supposed to stop ad ware and spy ware, but mostly seems to enforce m$...  This is a rant I know I could do for hours.

Can you connect with your linux boxes then?

Always been possible to connect from linux.  I wanted to develop on windows to avoid cross compiling.  also there is Lazarus and gentoo's little squabble.

jonathan

[jacem]

Okay oddness.

With the file libpq.dll, ssleay32.dll libeay32.dll, iconv.dll copied into the working directory, if I open the project by double clicking the xxx.lpi or xxx.lpr file in the working directory I can set the TPQConnection connected property to true. 

If I open clean copy of lazarus and place the connection on the form or try to open an existing project File->Open from the file menu with a TPQConnection switching the connected property to true gives me the error.

The built xxx.exe will work on a machine that has neither lazarus or postgreSQL installed as long as a copy of libpq.dll is in the application directory with it.

I don't know if I should call this solved or open a bug report.

jonathan