Does this change mean that data entered for single event without registration will be stored in the trackedentitydatavalue table instead of patientdatavalue table. I am working on a single event without registration program. Aggregation does not work at all for all the aggregation queries. I copied the data from the patientdatavalue table to the trackedentitydatavalue table and this works (crooked way to go about it but experimenting). It would be useful to know which table the event capture app stores data and how this might help my case.
Can anyone advise? I have already logged an entry on the user list about the requirements.
what happened here is simply that we have removed the web user interface in “individual records” module for capturing single events with registration. You will find the same functionality with a simpler and better user interface in the new “event capture” app.
The database (or dhis service layer) does not change at all due to this, and is not related to aggregation queries.
For upgrading between 2.14 and 2.15 you must run the upgrade script which you can find next to the war file on dhis2.org/downloads, direct link:
This will rename the tables from patient* to trackedentity*
cheers
Lars
···
On Wed, May 7, 2014 at 4:25 PM, Adebusoye Anifalaje busoye@hisp.org wrote:
Does this change mean that data entered for single event without registration will be stored in the trackedentitydatavalue table instead of patientdatavalue table. I am working on a single event without registration program. Aggregation does not work at all for all the aggregation queries. I copied the data from the patientdatavalue table to the trackedentitydatavalue table and this works (crooked way to go about it but experimenting). It would be useful to know which table the event capture app stores data and how this might help my case.
Can anyone advise? I have already logged an entry on the user list about the requirements.
This was a bit confusing because it seemed the upgrade script had been run but there is still a Patientdatavalue table with data in it. What happens if the database had been upgraded to 2.15 and used extensively before the upgrade script is run. I just tried to run the upgrade script again and get the message: ERROR: table “patientaggregatereportmembers” does not exist.
what happened here is simply that we have removed the web user interface in “individual records” module for capturing single events with registration. You will find the same functionality with a simpler and better user interface in the new “event capture” app.
The database (or dhis service layer) does not change at all due to this, and is not related to aggregation queries.
For upgrading between 2.14 and 2.15 you must run the upgrade script which you can find next to the war file on dhis2.org/downloads, direct link:
This will rename the tables from patient* to trackedentity*
cheers
Lars
On Wed, May 7, 2014 at 4:25 PM, Adebusoye Anifalaje busoye@hisp.org wrote:
Does this change mean that data entered for single event without registration will be stored in the trackedentitydatavalue table instead of patientdatavalue table. I am working on a single event without registration program. Aggregation does not work at all for all the aggregation queries. I copied the data from the patientdatavalue table to the trackedentitydatavalue table and this works (crooked way to go about it but experimenting). It would be useful to know which table the event capture app stores data and how this might help my case.
Can anyone advise? I have already logged an entry on the user list about the requirements.
This was a bit confusing because it seemed the upgrade script had been run
but there is still a Patientdatavalue table with data in it. What happens
if the database had been upgraded to 2.15 and used extensively before the
upgrade script is run.
That is a bit bad. See below.
I just tried to run the upgrade script again and get the message: ERROR:
table "patientaggregatereportmembers" does not exist.
It is not a problem that certain statements in the script fail. That simply
means that the table has been removed or renamed earlier. Just make sure
that all statements in the script are executed, failing or succeeding.
Ideally you should run the upgrade script before deploying 2.15. If not,
some manual execution of the upgrade script statements must be done.
Starting DHIS 2.15 on a blank database and comparing that with your db is a
good tip.
Lars
···
On Wed, May 7, 2014 at 5:39 PM, Adebusoye Anifalaje <busoye@hisp.org> wrote: