Backup from tryton 3.8 client dump Ubuntu OS to restore to 4.2 OpenSUSE Leap KDE 42.3 OS Server

[Maah Moussa]

Hello Tryton Community,
The *.dump from the Tryton 3.8 client platform copied to the new server converted to *.sql through command: pg_restore -f *.dump *.sql

psql -c "CREATE USER gnuhealth WITH CREATEDB;"
createdb gnuhealth0 –owner=gnuhealth
psql gnuhealth0 < /directory/*.sql

psql -c "ALTER DATABASE gnuhealth0 OWNER to tryton;"
psql -c "GRANT gnuhealth to tryton;"

psql -c "CREATE USER tryton WITH CREATEDB;"

The DB gnuhealth0 shows in the tryton 4.2 client but trying to connect the message comes up:
Traceback (most recent call last):
File "/trytond/wsgi.py", line 47, in dispatch_request
return endpoint(request, **request.view_args)
File "/trytond/protocols/dispatcher.py", line 41, in rpc
request, database_name, *request.rpc_params)
File "/trytond/protocols/dispatcher.py", line 53, in login
database_name, user, parameters, language=language)
File "/trytond/security.py", line 24, in login
User = pool.get('res.user')
File "/trytond/pool.py", line 170, in get
return self._pool[self.database_name][type][name]
KeyError: 'res.user'
Sometimes Missing dependencies: ['purchase_request']
Thanks for the help
MMoussa

[Sergi Almacellas Abellana]

El 22/09/17 a les 12:55, Maah Moussa ha escrit:

> Hello Tryton Community,
> The *.dump from the Tryton 3.8 client platform copied to the new server converted to *.sql through command: pg_restore -f *.dump *.sql

I think this is not suported. If you are going to restore it with
pg_restore you should use the pg_dump in order to get the backup.



--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

You have to follow the migration path from 3.8 to 4.2: https://discuss.tryton.org/c/migration
And perform an update of the database: http://doc.tryton.org/4.4/trytond/doc/topics/setup_database.html#topics-setup-database

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Axel Braun]

Is the module purchase_request installed?

>
>You have to follow the migration path from 3.8 to 4.2:
>https://discuss.tryton.org/c/migration
>And perform an update of the database:
>http://doc.tryton.org/4.4/trytond/doc/topics/setup_database.html#topics-setup-database

Please see the README. SUSE as well for upgrade hints

Cheers
Axel

[Maah Moussa]

It seems to be installed.
I have been using the README.SUSE. I also get this message when trying to upgrade the database in the current situation:

Traceback (most recent call last):

File "/usr/bin/trytond-admin", line 21, in <module>
admin.run(options)
File "/usr/lib/python3.4/site-packages/trytond/admin.py", line 24, in run
with Transaction().start(db_name, 0):
File "/usr/lib/python3.4/site-packages/trytond/transaction.py", line 87, in start
database = Database(database_name).connect()
File "/usr/lib/python3.4/site-packages/trytond/backend/postgresql/database.py", line 94, in connect
minconn, maxconn, self.dsn(self.name))
File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 156, in __init__
self, minconn, maxconn, *args, **kwargs)
File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 58, in __init__
self._connect()
File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 62, in _connect
conn = psycopg2.connect(*self._args, **self._kwargs)
File "/usr/lib64/python3.4/site-packages/psycopg2/__init__.py", line 164, in connect
conn = _connect(dsn, connection_factory=connection_factory, async=async)
psycopg2.OperationalError: FATAL: role "root" does not exist

Thanks

Maah Moussa

[Maah Moussa]

Is the migration path a must to be used in any way the dump is taken, gnuhealth-control or client dump when moving between series?
Do I need to follow from 3.8 to 4.0 then 4.0 to 4.2?
Does it matter before or after restoring the database?
How to apply this SQL queries into SQL plain text on OpenSUSE? A hint on how to apply [SQL] or [PY] changes would be much appreciated. the command is not available.

Thanks
Maah Moussa
mmo...@sharabclinic.com

[Cédric Krier]

On 2017-09-22 10:20, Maah Moussa wrote:
> > Is the module purchase_request installed?
> >

> It seems to be installed.

But it must be activated on the database so the update must be:

--all -u purchase_request

This is a new module on which new version of activated module depends.

> I have been using the README.SUSE. I also get this message when trying to upgrade the database in the current situation:
> Traceback (most recent call last):
> File "/usr/bin/trytond-admin", line 21, in <module>
> admin.run(options)
> File "/usr/lib/python3.4/site-packages/trytond/admin.py", line 24, in run
> with Transaction().start(db_name, 0):
> File "/usr/lib/python3.4/site-packages/trytond/transaction.py", line 87, in start
> database = Database(database_name).connect()
> File "/usr/lib/python3.4/site-packages/trytond/backend/postgresql/database.py", line 94, in connect
> minconn, maxconn, self.dsn(self.name))
> File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 156, in __init__
> self, minconn, maxconn, *args, **kwargs)
> File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 58, in __init__
> self._connect()
> File "/usr/lib64/python3.4/site-packages/psycopg2/pool.py", line 62, in _connect
> conn = psycopg2.connect(*self._args, **self._kwargs)
> File "/usr/lib64/python3.4/site-packages/psycopg2/__init__.py", line 164, in connect
> conn = _connect(dsn, connection_factory=connection_factory, async=async)
> psycopg2.OperationalError: FATAL: role "root" does not exist

The configuration of the database connection seems to be wrong.

On 2017-09-22 10:15, Maah Moussa wrote:
> On Friday, September 22, 2017 at 1:35:07 PM UTC, Cédric Krier wrote:

> > You have to follow the migration path from 3.8 to 4.2: https://discuss.tryton.org/c/migration
> > And perform an update of the database: http://doc.tryton.org/4.4/trytond/doc/topics/setup_database.html#topics-setup-database
>

> Is the migration path a must to be used in any way the dump is taken, gnuhealth-control or client dump when moving between series?

I do not know about gnuhealth-control.
But migration must always be done when changing the version.

> Do I need to follow from 3.8 to 4.0 then 4.0 to 4.2?

Yes, all the migration operation must be done.
You can just made the database update on the last one normally.

> Does it matter before or after restoring the database?

You can not do the migration before restoring the database because you
do not have a database to update.

> How to apply this SQL queries into SQL plain text on OpenSUSE? A hint
> on how to apply [SQL] or [PY] changes would be much appreciated. the
> command is not available.

Run the sql query using the psql command:
https://www.postgresql.org/docs/9.2/static/app-psql.html

[Maah Moussa]

trytond-admin -d gnuhealth30 -c trytond.conf -u purchase_request --all
result:

Traceback (most recent call last):
File "/usr/bin/trytond-admin", line 21, in <module>
admin.run(options)
File "/usr/lib/python3.4/site-packages/trytond/admin.py", line 24, in run
with Transaction().start(db_name, 0):
File "/usr/lib/python3.4/site-packages/trytond/transaction.py", line 87, in start
database = Database(database_name).connect()

File "/usr/lib/python3.4/site-packages/trytond/backend/sqlite/database.py", line 242, in connect
raise IOError('Database "%s" doesn\'t exist!' % db_filename)
OSError: Database "gnuhealth30.sqlite" doesn't exist!

I restored the same Database with same procedures into 3.8 and it works.
I tried psql your_db_name < upgrade_32.sql
Result:
ERROR: column "category" of relation "product_template" does not exist
UPDATE 0
UPDATE 0
ERROR: column "active" of relation "gnuhealth_patient" does not exist
LINE 3: update gnuhealth_patient set active=True;
^
ERROR: column "active" of relation "gnuhealth_medicament" does not exist
LINE 2: update gnuhealth_medicament set active=True;
^
ERROR: column "active" of relation "gnuhealth_healthprofessional" does not exist
LINE 2: update gnuhealth_healthprofessional set active=True;
^
ERROR: column "active" of relation "gnuhealth_lab_test_type" does not exist
LINE 2: update gnuhealth_lab_test_type set active=True;
^
ERROR: column "active" of relation "gnuhealth_imaging_test" does not exist
LINE 2: update gnuhealth_imaging_test set active=True;
^
ERROR: relation "gnuhealth_ambulance" does not exist
LINE 2: update gnuhealth_ambulance set active=True;

Going psql db_name
UPDATE 0
after UPDATE account_tax_template SET credit_note_base_sign = credit_note_base_sign * -1, credit_note_tax_sign = credit_note_tax_sign * -1;
and UPDATE account_tax_template SET credit_note_base_sign = credit_note_base_sign * -1, credit_note_tax_sign = credit_note_tax_sign * -1;

Thanks

[Axel Braun]

Trytond seems to be connected to sqlite, not to postgres. -> Your dB definition in trytond.conf is wrong. Fix this first

[Maah Moussa]

Yes. Thanks. It got connected as postgres after running trytond-admin correctly. The DB is working. Except the invoicing It gets this message:
The value of the field "Account" on "Invoice" is not valid according to its domain.
I used the migration through opensuse upgrade.sql
All seems working except the invoicing.

[Sergi Almacellas Abellana]

El 27/09/17 a les 12:11, Maah Moussa ha escrit:

> Yes. Thanks. It got connected as postgres after running trytond-admin correctly. The DB is working. Except the invoicing It gets this message:
> The value of the field "Account" on "Invoice" is not valid according to its domain.
> I used the migration through opensuse upgrade.sql
> All seems working except the invoicing.

The invoice domain enforces two things:

1. The account used is from the same company as the invoice account.
2. If it's an out invoice it should be of kind receivable. Otherwise it
should be of kind payable.

One (or both) of this conditions is not valid. You should check the
values used.

[Maah Moussa]

The restored DB used to have invoiced customers. Now I can't invoice customers even after putting the customer payment term.
I'm sorry. I don't quite grasp your points. The accounts are configured and used to be working.
Also I noticed issues through back up
2017-09-27 12:19:03 [INFO] START Database Backup
2017-09-27 12:19:06 [INFO] Compressing Database Backup
2017-09-27 12:19:09 [INFO] Creating compressed tarball with DB and GNU Health Attachment directory
tar: Removing leading `/' from member names
/var/lib/tryton/
/var/lib/tryton/trytond.pid
./gnuhealth-control: line 183: message: command not found
tar: Removing leading `/' from member names
/home/gnuhealth/Downloads/backup_gnuhealth30_2017-09-27_121903.gz
tar: /home/gnuhealth/Downloads/gnuhealth_gnuhealth30_fs_backup_2017-09-27_121903.tar.gz: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
2017-09-27 12:19:09 [ERROR] Bailing out !
2017-09-27 12:19:09 [ERROR] Removing backup lock file

Is there a method to make sure the DB is restored and migrated correctly?
Thanks
Thanks

[Axel Braun]

.

Am 27. September 2017 16:19:27 OESZ schrieb Maah Moussa <maahm...@gmail.com>:
>On Wednesday, September 27, 2017 at 12:17:20 PM UTC, Sergi Almacellas
>Abellana wrote:
>> El 27/09/17 a les 12:11, Maah Moussa ha escrit:
>> > Yes. Thanks. It got connected as postgres after running
>trytond-admin correctly. The DB is working. Except the invoicing It
>gets this message:
>> > The value of the field "Account" on "Invoice" is not valid
>according to its domain.
>> > I used the migration through opensuse upgrade.sql

This is the standard upgrade script provided by GNU Health (just for the records)

Indeed, instead of 'message' it should read 'cli_msg'.
I trust Luis will correct this once he is back from Africa. For the openSUSE Version I did a correction to Factory tree already

>tar: Removing leading `/' from member names
>/home/gnuhealth/Downloads/backup_gnuhealth30_2017-09-27_121903.gz
>tar:
>/home/gnuhealth/Downloads/gnuhealth_gnuhealth30_fs_backup_2017-09-27_121903.tar.gz:
>Cannot stat: No such file or directory
>tar: Exiting with failure status due to previous errors
>2017-09-27 12:19:09 [ERROR] Bailing out !
>2017-09-27 12:19:09 [ERROR] Removing backup lock file
>
>Is there a method to make sure the DB is restored and migrated
>correctly?

Don't mix things up: restoration and migration are two different things.
First make sure you took a proper backup - use pg_dump for this (actually gnuhealth_control uses this in the background as well), and pg_restore to restore - it should tell you the errors that appear. Same for the upgrade script.

Viele Grüße
Axel
--
Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet

[Maah Moussa]

It seems that the issue of invoicing is not related to the restored DB, as the same message " The value of the field "Account" on "Invoice" is not valid
>according to its domain. " comes up in a different server with a new DB when invoicing health service.

I will be using the pg_dump to backup for now.
Thanks

[Axel Braun]

>It seems that the issue of invoicing is not related to the restored DB,
>as the same message " The value of the field "Account" on "Invoice" is
>not valid
>>according to its domain. " comes up in a different server with a new
>DB when invoicing health service.

Can you reproduce this on the demo-server? If so, please create a step-by-step description and send it to health...@gnu.org

Thanks
Axel