I have two separate computers, each of which are running ArcGIS Desktop 10.3.1 and PostgreSQL and PostGIS 2.1.7. The only difference is one is running PostgreSQL 9.3.4, the other is running 9.3.5.

I am trying to make a simple (or what should be simple) connection to DBMS. I have properly copied all of the PostgreSQL client files ( libeay32.dll, libiconv-2.dll, libintl-8.dll, libpq.dll, and ssleay32.dll) to the ArcGIS bin directory. The pg_hba.conf for each is set to accept client connections. And, of course (of course!!!), I have no problem whatsoever connecting to either using other clients, such as QGIS. However, when I try to add a database connection using ArcGIS Desktop, it works splendidly on one machine (the one running 9.3.4), but not on the other. The error I receive is “Unable to connect to database server to retrieve database list; please verify your server name, user name and password info and try again. Cannot connect to database because the database client software failed to load. Be sure the database client software is installed and correctly configured.”

I have searched high and low to solve this issue and, as a result, have wasted more time than I would like to admit. I am debating if it is more maddening than frustrating or vice versa. If the option was to use another client, such as QGIS, I would. Obviously, it is not. Since I can connect just fine on one machine, I know it actually should work (and the version difference of PostgreSQL really shouldn’t matter).

  • That's odd, since the Requirements site states that the minimum supported 9.3 PG is 9.3.5. Unless you're saying that the host with 9.3.4 libraries can't connect to the 9.3.5 box, in which case this makes a kind of sense. Have you tried using the supported libraries on both hosts?
    – Vince
    Commented Oct 1, 2015 at 15:26
  • It is indeed odd. The host with the 9.3.4 libraries connects without a hitch. Both are just localhost connections. I am not trying to connect to one box from the other. Localhost connection with the 9.3.4 works great. Localhost connection on the box with the 9.3.5 libraries--fail.
    – Todd Fagin
    Commented Oct 1, 2015 at 15:36
  • It might be instructive to try connecting across hosts. You should also try reinstalling Desktop, since it already should have appropriate client libraries. Otherwise, this looks like an issue for Tech Support.
    – Vince
    Commented Oct 1, 2015 at 16:02
  • The issue has been resolved, but I am still unsure of what the problem was. I am also flummoxed as to why 9.3.4 works great when it shouldn't. Anyway, I am new to Stack Exchange and do not know how to mark as resolved. I will explain in a separate post since I reached character limit when I tried to include it here.
    – Todd Fagin
    Commented Oct 1, 2015 at 17:01

2 Answers 2


This issue has been resolved. I have learned (thanks to Vince, as well as an individual on the GeoNet list) that it is no longer necessary to copy the client files as it was prior to 10.3. Used to the old method, I may have overwritten the client files that installed with 10.3.1. Despite having previously copied the client files from the working box to the broken one in a futile attempt to fix the problem, I did it again and it worked. Did I do something differently? Apparently so.

  • Did you copy the (unsupported) 9.3.4 libraries from the other (working) host? Clobbering the 9.3.5 libs with 9.3.4 libs might make sense on the host with 9.3.4, but it doesn't with the host using 9.3.5.
    – Vince
    Commented Oct 1, 2015 at 17:31

There seems to be a known bug causing this issue described in ESRI technical support (last published in 2016). From what I understand, if the given user has roles in other databases in the server cluster this causes a bug (that might be the difference between your two computers?).

They prescribe to remove the other roles of the user.

Alternatively, you can also add a new dummy user and input that user to connect from arcgis (this solved the issue for me, but I have a different PostgreSQL version).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.