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@harte-lyne.ca> 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@aklaver.com
