On 10/2/20 7:17 PM, James B. Byrne wrote:
On Fri, October 2, 2020 21:13, Tom Lane wrote:
"James B. Byrne" <byrnejb@xxxxxxxxxxxxx> writes:
On Fri, October 2, 2020 18:46, Tom Lane wrote:
The two likely possibilities are that Idempiere isn't connecting to the
same database as you are doing manually, or that it is using a search_path
setting that doesn't include the "public" schema.
I think you could also get this if the "public" schema is not readable
by Idempiere's userid, but that doesn't seem terribly likely.
idempiere=# \dn
List of schemas
Name | Owner
-----------+-----------
adempiere | adempiere
public | postgres
Uh ... that rules out exactly none of those three possibilities.
"\dn" says what schemas exist, but it tells you nothing about
either search_path or privileges.
You could try "select current_schemas(true)" to narrow things
down a little bit, as that would show the active search path
in your session.
regards, tom lane
Sorry about that. Still finding my way. Anyway, I believe that I may have
found the problem. When I created the test database I was following the
software installation guide. The user the guide refers to is 'adempiere' and
not 'idempiere_dbadmin'. At some point I came at the task from a different pov
and created another user to be the database owner. Cannot say why but it is
evident that is what I did.
I will resolve the conflict either by granting 'idempiere_dbadmin' the
necessary privileges or by changing the connection to use the 'adempiere' user
instead.
I'm not sure that is going to help. You are not, AFAICT, getting any
permission denied messages.
What does:
\df+ uuid_generate_v4
show under Access privileges?
What does:
select current_schemas(true);
show?
Thanks for the pointers.
Regards,
P.S. If it turns out to be something else then I will return with more details.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
