This question is for those who have experience with Adempiere ERP.
when logging in, I get the error table ad_system is not found. connecting to Postgresql I can see the database along with the table name. not sure why it says so. anyone else experienced the same issue?
my Postgres user does have superuser permissions
[error message on login]
Try to query the database to see if it has data or if it's empty, for example:
SELECT * FROM AD_System
or
SELECT * FROM C_BPartner
That error usually appears when you do a bad DB restoration and the DB Tables are empty.
Related
In order to organize my local database server, I've executed DROP DATABASE postgres;. After it when I try to connect to database, it shows an error message:
database "postgres" does not exist
I've restarted the service; I've tried to reinstall postgres (install file:'postgresql-12.11-1-windows-x64'); I've tried to change the 'method' of file 'pg_hba.conf', from 'md5' to 'trust'. But the error continues.
Please, how can I create this 'postgres' database? Or other solution?
I've created a new server and then a new database. When I was recreating a database, I identified that the database 'postgres' is automacally created, and to create a my database is necessary set a owner, and by default the owner is 'postgres'.
Note: Maybe this suggestion (How to recover or recreate orginal Postgres database after dropping it?) could be work, when I saw this reply I'd already soluted how I described above.
According to my understanding of the PostgreSQL documentation, the role "pg_read_all_data" should grant the role holder the ability to execute "Select * from SCHEMA.TABLE" and similar to view the data. However, I'm unsure why this is not working out in practice for me.
I have created a sample schema and database on account "X" for example:
Image showing schema and table structure
However, when I log into role "Y" (with log in option enabled) with the role "pg_read_all_data" and try to execute:
SELECT * FROM test.test_table
Edit: I have assigned the role "pg_read_all_data" via the command: GRANT pg_read_all_data to "Y" on a superuser role.
It throws a permission error: SQL Error [42501]: ERROR: permission denied for schema test
Position: 15
I'm a little lost on why this is the case when the role should've granted select privileges. Can someone tell me why this is happening?
Closed - After a few days away, I went back to the issue and it seemed to have resolved itself.
I have a Oracle Database 12C and, when i do the following query on SYS schema
select * from all_users;
i get listed USER_X.
However, when i try to alter USER_X's password, by doing the following
ALTER USER USER_X IDENTIFIED BY XPTO_123;
i get the error
SQL Error: ORA-01918: 01918. 00000 - "user '%s' does not exist"
Am i missing something?
Thanks
How was the 12C database installed? Does it uses the "Multitenant" architecture?
If so, alter the user's password may differ for CDB and PDB.
You can refer to this and this links for more infos.
I am using Oracle 11g client 32bit on all my servers and i have proceeded with all the dump imports the very same way I am doing here.
Firstly I create the user with default tablespace
Secondly I alter the user quota unlimited on tablespace
Thirdly I grant connect resource dba to the user.
Then I exit from Oracle and this is my import command
C:\Users\romit.poladiya>imp fajbdummy/fa#dmate file='E:\dump\fajblatest.dmp' full=Y;
I have always been doing this and I do not know why I have not been able to import this time. Please assist. Let me know if you require any more information
Thanking the team in advance,
Romit
ORA-01017: invalid username/password; logon denied
Cause: An invalid username or password was entered in an attempt to log on to Oracle. The username and password must be the same as was specified in a GRANT CONNECT statement. If the username and password are entered together, the format is: username/password.
Cure: Use the correct username & password. Check the system to make sure that the username exists, and set the password if necessary.
The following issue can be closed as I was able to do the tnsping but unfortunately my oracle went into an Idle Instance while I was connecting. Earlier it was not an issue and I have no idea whatever happened and the the oracle just went into Shutdown
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
postgresql database owner can't access database - “No relations found.”
The core problem: I have a Django website that's complaining about relations (tables) not existing when I connect to it after attempting to run a SQL script generated by pg_dump MY_DATABASE_NAME -cOx -E UTF8 > MY_SCRIPT_NAME.sql
Before running the script I'd could connect and all was right with the world.
After running the script I live in a world of pain that I've attempted to alleviate by examining and altering ownership of MY_DATABASE_NAME and tables using the various methods described in Modify OWNER on all tables simultaneously in PostgreSQL
It would seem that I can only see relations via \dt on MY_DATABASE_NAME only after having first logged in as the postgres user on my server like so: sudo su - postgres.
When I SSH and run psql MY_DATABASE_NAME -U MY_NON_POSTGRES_USER without switching to the postgres user, \dt' results in ano relations found` message.
At first I presumed permissions or ownership was the problem. I logged-in as my server's postgres user and changed owner of MY_DATABASE_NAME and all of its tables to MY_NON_POSTGRES_USER.
Same results as before. Relations show up for my postgres user, but logging in as another role results in a 'no relations found message', and my website complains that 'relation some_table doesn't exist'
Why is this happening to me?
Wow. I really just composed a TL;DR description of my question and realized immediately afterwards my folly:
Although I'd connected to MY_DATABASE_NAME and given ownership to the correct user for all tables and the database, I'd forgotten to:
REVOKE ALL ON SCHEMA public FROM MY_NON_POSTGRES_USER;
GRANT ALL ON SCHEMA public TO MY_NON_POSTGRES_USER;
No more pain. All is right with the world again.