Dear Bernard,
You are absolutely right. The program_userroles table is the correct one, and
the userroleprogram table is a legacy table not used anymore. We just fixed the
script, please try again with the latest version.
Best regards,
Markus
> 9. mar. 2018 kl. 14:21 skrev Bernard Sadaka (IM
Dear Markus,
After a closer look, I found this table:
public | program_userroles | table | dhis
Is it the same?
All the best,
Bernard
Bernard Sadaka
Information Management Advisor
Première Urgence - Aide Médicale Internationale
Nehmeh Building, Sanine Street, Chiyah,
Hello Markus,
Unfortunately I don’t have that table:
dhisdb=# \dt userrole*
List of relations
Schema | Name| Type | Owner
+---+---+---
public | userrole | table | dhis
public |
Hi Dan!
You are are absolutely right. The script currently triggers a migration of data
into the programstageusergroupaccesses before this table is created.
To get around the problem right away you need to run the script except for the
last line, then start the server, and run the last line of
Hi there Bernard,
that was strange - your 2.28 database should have contained the table
userroleprogram.
Assuming you are running 2.28, can you try running this query on your command
line?
\dt userrole*
Expecting that one of the lines output is:
public | userroleprogram | table | dhis
Hi devs,
The generated ID is a nice feature we were looking for. Thanks!
However now I am wondering. In the user guide it specifies:
"Sequential segments will be replaced by a number, based on a counting
value on the server."
How do I do to find this value on the server? Through API or
Dear All,
I am trying to migrate from 2.28 (aff610f) to 2.29, by first running the
upgrade script and then updating the .war file.
However I am stuck at the upgrade script with this error:
Please advise.
All the best,
Bernard
Bernard Sadaka
Information Management Advisor
Première
7 matches
Mail list logo
