Database restore problem

Hello everybody,

after quite some progress with all my tryton stuff, I’m stuck at a point I easily could go around some time ago. What I did in pip virtual environments:

  • set up an install “tryton-Muster”
  • created a list of modules with pip freeze --local > list.lst
  • wrote a sql dump pg_dump -U -d old-database-name > database-dump.sql
  • changed the version numbers of all tryton modules in the modules list to the desired 6.0.*
  • created a new virtual environment with the necessary components
  • created a new database
  • imported the dump into the new database psql -U username -d new-database < database-dump.sql
  • executed trytond-admin -c trytond.conf -d new.database --all -vv

The last step produced:

$ trytond-admin -c trytond.conf -d try-60-Muster2 --all -vv
62902 139916808533824 [2022-02-04 17:11:30,681] INFO trytond.backend.postgresql.database connection to "try-60-Muster2" succeeded
62902 139916808533824 [2022-02-04 17:11:30,688] INFO trytond.admin init db
Traceback (most recent call last):
  File "/home/wd/TRYTON/try-60-Muster2/bin/trytond-admin", line 23, in <module>
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/", line 31, in run
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/backend/postgresql/", line 364, in init
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/backend/postgresql/", line 72, in execute
    cursor.execute(self, sql, args)
psycopg2.errors.DuplicateTable: relation "ir_configuration_id_seq" already exists

I did that procedure several times without trouble, but now there must be a silly mistake… Can somebody decipher that for me - @edbo, this may be for you… (-;


For me you have restored a partial dump of the database. So trytond-admin see the database as a new one and try to create tables that already exists.
So you should check the correctness of your backups.

I think that with this command your dump will be empty. You can easily do a tail or cat to see if your dump has anything in it. The reason you will have an empty database dump is because you use the -U but didn’t specify the user. So your command should be like:

pg_dump -U <pgbackupuser> -d old-database-name > database-dump.sql

Thank you very much.
Well, again I was not precise enough. The special task is to export a database which can be imported by another database owner. (Idea in the background is to provide a pre-configurated database to tryton newbies)

I checked database contents - it’s not empty. I found my parties, articles etc.

I guess I messed the -U and the -O option, so I tried:
sudo pg_dump -O -d try-60-Muster > try-60-Muster.sql.

This works as well, dump can be written into the database. But I get the same error when doing
$ trytond-admin -c trytond.conf -d try-60-Muster --all -vv.


If the backup is complete and the original database is a valid Tryton’s database. Then it is probably a problem of access right.

This might be another topic, but I prefer a proteus script.

You folks can find the database dump here:

Maybe you can find what’s wrong with it.

Certainly that’s the better solution - but as I know nothing at all about proteus, I cannot really know far I can get with that approach and how much effort it would be.

I tried your SQL-dump and it just worked. So no problem there. But I think it is a access problem. Not in the database, but in Tryton.

As you said, you export a database as a certain user, then import it as another user. This also means that you also have to change the user / password in your trytond.conf to match the new database user.

We should open a new topic if we need to exchange on this kind of wellcome database.
Currently a new user gets his initial database with the name of his company and his fiscal year preferences. WIP: I also need to import some demo data / training data.

Well, I’ve got several tryton installs on my machine. All of them are using the same trytond.conf. So that one should be correct. Trying to review the error message:

trytond-admin -c trytond.conf -d try-60-Muster2 --all -vv
25205 140640029333312 [2022-02-05 14:49:17,001] INFO trytond.backend.postgresql.database connection to "try-60-Muster2" succeeded
25205 140640029333312 [2022-02-05 14:49:17,007] INFO trytond.admin init db
Traceback (most recent call last):
  File "/home/wd/TRYTON/try-60-Muster2/bin/trytond-admin", line 23, in <module>
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/", line 31, in run
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/backend/postgresql/", line 364, in init
  File "/home/wd/TRYTON/try-60-Muster2/lib/python3.8/site-packages/trytond/backend/postgresql/", line 72, in execute
    cursor.execute(self, sql, args)
psycopg2.errors.DuplicateTable: relation "ir_configuration_id_seq" already exists

It says it connects to the database. What does the last line mean?

Love that wording. Unluckily, it does not work in German. But we are working on the concept. (Well, trying to… :wink:)

Tryton connected successfully to the database

This says, Tryton found the the database but it’s empty (no tables or sequences etc) so it will start filling it with the base (modules ir and res)

This says that there is already a table ir_configuration_id_seq in the database. So there is something wrong. What does pgadmin say when you connect to the database with the Tryton credentials?

I can look into the database and checked articles, parties, currencies I had created in the “Muster” environment. All of them are present in the new “Muster2” database. So it looks as if some sort of import process happened.

The only thing left, is just drop the new database create it again and import the sql-dump and try it again.

I already tried this several times - always running into the same error. I checked import messages of the dump - nothing. I manually synced source and target VENV to make sure both have precisely the same versions. Always the same error. And I tried the whole procedure on a friend’s virtual machine. Always the same error.

There must be a very simple and embarrassing mistake I’m repeating over and over again. Can you tell me what’s the most stupid thing you can think of?

Here’s the list of pip components I’m using. Did I leave out any essential?

mds-account-de-skr04 @ file:///home/wd/TRYTON/try-60-Muster/mds_account_de_skr04-6.0.0-py3-none-any.whl

Indeed there is no other explanation … :cry: Because I used your list of components, created a new virtual environment, installed the components (except for the mds-addount, pkg-resources and psycopg2 because the first one is not available and the rest gave some errors so I installed them manually) and restored your database dump and used the trytond-admin without any problems.

So what I did:

  1. Restore you database dump (did this as postgres user)
    • create a new database: createdb -O trydbuser try-60-muster
    • dump you sql into the database psql -U trydbuser try-60-muster < /tmp/try-60-Muster.sql
  2. Create a new virtual environment, installed your list of components, ran trytond-admin (did this as a regular user)
    • python3 -m venv --system-site-packages testpip
    • cd into the testpip and activate it . bin/activate
    • Create a file and put the requirements in it
    • Run pip install --upgrade -r requirements.txt
    • Create a trytond.conf with minimal contents:
      uri = postgresql://trydbuser:mysecretpassword@localhost:5432/
    • Run trytond-admin with trytond-admin -c trytond.conf -d try-60-muster --all -vv

Small sidenote, because of the mds-account I had to manually mark the module as not activated in Postgresql. But that shouldn’t make any difference.

Thanks for so patiently listing up the steps once again. Hope some other fellow will benefit from that one day.

It’s so strange.
It came to my mind that I changed “language=en” to “language=de” in trytond.conf - and I was close to certain that this only can be the culprit. But it was not. ))):

Could it be a matter of my python? Mine is Python 3.8.10.

trytond tries to create the sequence ir_configuration_id_seq because it thinks it does not exist (but it exists). So this means that the PG user used to connect to PostgreSQL by trytond can not see this sequence in the information_schema.sequences (or that the psycopg2 version does not count row correctly). This can be because of access rights or the search_path.

What OS do you use? I can create a new VM with that OS and try it again. But as @ced says, there is something wrong between Tryton and PostgreSQL. So check your connections very carefully and play with the trytond.conf, try just with the necessary lines. Also drop the database, create a new one and try again. Look also who owns the database, tables, sequences etc (with pgadmin). Make sure you are running the right virtual environment with the right configuration.

I’m really embarrassed how much effort I’m causing.

I’m on ubuntu 20, and the VM I tried is an ubuntu as well (not sure which, recent anyway).

I checked a random selection of tables with PgAdmin. All of these tables are owned by user “postgres”. Other databases I’m using are owned by user “wolf”. That does not sound correct - true?

Yes, that’s the problem! I think you are using the user “wolf” also in the trytond.conf? When you change the owner of the database etc to “wolf” then Tryton should be able to see the tables.

If that’s the case, then you missed the -U in the psql command.