Subscribe to this thread
Home - General / All posts - Can't check in changes, or share new components on Enterprise server postgres

863 post(s)
#12-Feb-20 01:04

I've just set up Manifold 8 on 4 new laptops (latest 32 bit version of 8, Windows 10 64 bit)

Three of them are fine but on the 4th I can connect to our postgres enterprise server via server console, but get an error when trying to check in modified layers (couldn't update enterprise server)

I get a slightly different "table does not exist" error, if trying to share a new component to enterprise server.

Seems like an issue with write permissions to the database but..

I've checked account permissions, the account works fine with server console on other computers.

I've uninstalled and reinstalled the postgresql odbc driver.

I've deleted and re-added the odbc connection.

None of this seems to help.

Anyone have ideas of what else to try?


9,321 post(s)
#12-Feb-20 07:37

To be clear, are you using different PostgreSQL logins for different machines or the same login?

If you are using different logins and can share / check in components from some machines but not others, try switching the login on the machine where share / check in does not work. If one login works and a different login does not, check differences between their permissions on the database. Sharing / checking in needs permissions to create tables in the user's schema.

If you are using the same login, check versions of database drivers. Could it be that you are connecting to PostgreSQL not via the ODBC driver but via a native connection? In that case, Manifold 8 connects directly through LIBPQ.DLL. On the machine that fails, find all instances of LIBPQ.DLL, then make sure that Manifold 8 (x86) finds the correct one (also x86 and the same version as on the machines that work). If you are connecting using ODBC, make sure that you have the 32-bit version of the ODBC driver installed.


863 post(s)
#12-Feb-20 09:26

I initially had different logins, but tested this, and the new login worked fine on other machines.

I also tried my own well used login on the new machine and it failed there.

I am setting up the connection through server console on the new machine by selecting the postgresql driver the same as I have for all other machines. Is there anyway that could set up a native connection? I thought I needed database console to do that.

I have uninstalled and reinstalled the 32bit odbc driver to make sure it is the correct one.

I suspect I have done something very simple wrong somewhere, but can't imagine what it was.


9,321 post(s)
#12-Feb-20 13:00

I checked and you are right, Server Console uses ODBC.

Since the same login works from one machine but not the other, the problem is with the machine configuration.

You might be having multiple instances of PostgreSQL DLLs and the system might have PATH pointing to older versions. (Search for all instances of LIBPQ.DLL or siblings, inspect PATH and clean it from the unwanted folders.)

If there is any type of runtime monitoring software, like antivirus packages, they might be blocking some of the PostgreSQL DLLs, preventing them from running. (Temporarily pause the monitoring, relaunch Manifold, see if this will fix the issue.)

There might also be a configuration issue with PostgreSQL DLLs, eg, one of the DLLs might be referencing a system DLL that is not there (unlikely) or is of a wrong version and is incompatible with the PostgreSQL DLL (more likely). (Run Windows Update until it stops discovering new updates, unhide any updates you might have hidden.)


863 post(s)
#14-Feb-20 09:10

I haven't checked those dlls yet.

I have managed to reproduce the problem on another computer though.

Exact error messages are

Checking in - "Can't check in component(s) to the Enterprise Server

Sharing - Error relation 'mfd3067_data' does not exist; Error while preparing parameters

I had a look at the connection and sharing strings and noticed a couple of differences from on a working computer.

To get them to match I changed the following advanced connection settings from the default.

<!--[if gte mso 9]> 800x600 <![endif]--><!--[if gte mso 9]> Normal 0 false false false EN-AU X-NONE X-NONE MicrosoftInternetExplorer4 <![endif]--><!--[if gte mso 9]> <![endif]--><!--[if gte mso 10]> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman",serif;} <![endif]-->

Page1 sys table prefixes dd_;

Page 2 server side prepare off

Bytea asLO off

This seems to have fixed the problem - I can now check in and share components.

I have no idea what those settings do though, or why I need to change them now when previously I've left everything default in the advanced settings.


863 post(s)
#14-Feb-20 09:35

obviously shouldn't have cut and pasted my notes from word. Ignore the stuff between default and Page 1


9,321 post(s)
#14-Feb-20 14:48

It seems to me the issue was not that the configuration of the machine with the original failures was *wrong*, but rather that it was *different* from the configuration of other machines. That is, the 'sys table prefix' setting generally has to be the same on all machines working with the same Enterprise storage, etc.

Glad it is now working!

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.