I’m having issues with reporting. If I apply any filter, I only get zeros for all indicators. For compostion queries, it only returns the fvalue for the first listed cohort, not the intersection or union. I’m using openMRS version 2.2.0 SNAPSHOT Build 88cc02, and reporting module 1.12.0. Things work as intended on the reference app, but I can’t figure out what would be causing this on our implementation. Any suggestions?
You will have to give more details about what you are doing, e.g. point to the code for the individual filters and composition, or share a screenshot of this.
-Darius (by phone)
Thank you for replying, your time is greatly appreciated. Here are screenshots showing the issue with the composition query:
Where female is a gender cohort query and age-17-to-24 is an age query (the name says under, that was a a typo). Here are the results:
where it returns only the result of the number of females. If I switch the order of the composition string, it returns the the count of patients within that age range.
For the filter in the period indicator report:
with the results being: 
If I remove the filter,
Interesting. What version of openmrs-core and the reporting module are you using?
Core Apps Module 1.13.0 Reporting 1.12.0
If it helps, here’s the rest of the system information:
OpenMRS Information Name Value System Date 2017-07-05 System Time 23:36:39 OpenMRS Version 2.2.0 SNAPSHOT Build 88cc02 Host Name Ubuntu-1610-yakkety-64-minimal
Java Runtime Environment Information Name Value Operating System Linux Operating System Architecture amd64 Operating System Version 4.8.0-52-generic Java Version 1.8.0_131 Java Vendor Oracle Corporation JVM Version 25.131-b11 JVM Vendor Oracle Corporation Java Runtime Name OpenJDK Runtime Environment Java Runtime Version 1.8.0_131-8u131-b11-0ubuntu1.16.10.2-b11 User Name tomcat System Language en System Timezone Europe/Berlin Filesystem Encoding UTF-8 Java User Home Directory / Temp Directory /opt/tomcat/temp
Memory Information Name Value Total Memory 1269 MB Free Memory 571 MB Maximum Heap Size 3545 MB
DataBase Information
Name Value
Database Schema Name openmrs
Database Connection URL jdbc:mysql://localhost:3306/openmrs?autoReconnect=true&sessionVariables=default_storage_engine=InnoDB&useUnicode=true&characterEncoding=UTF-8
Database User Name root
Database Driver Name
Database Dialect
Module Information Name Value Local repository /var/lib/OpenMRS/modules Atlas Module 2.2 Form Entry App Module 1.4.1 Reporting 1.12.0 Metadata Sharing 1.2.2 ID Generation 4.4.1 Allergy UI Module 1.7.0 EMR API Module 1.22.1 HTML Form Entry UI Framework Integration Module 1.6.3 App Framework Module 2.10.0 Reporting REST 1.8.0 Reference Metadata Module 2.6.0 Metadata Mapping 1.3.2 Admin UI Module 1.2.2 App UI Module 1.8.0 Metadata Deploy 1.8.1 OpenMRS UI Framework 3.11.0 Release Testing Helper 2.1 XForms 4.3.11 Reporting Compatibility 2.0.2 HTML Widgets 1.9.0 Serialization Xstream 0.2.12 Registration Core Module 1.7.1 Event Module 2.5 Core Apps Module 1.13.0 Provider Management Module 2.6.0 Calculation 1.2 Appointment Scheduling UI Module 1.6.0 Open Web Apps Module 1.7.0 HTML Form Entry 3.3.2 UI Commons Module 2.3.0 Rest Web Services OMOD 2.19.0.f2b4a2 Reporting UI Module 1.3.0 Appointment Scheduling Module 1.8.0 Legacy UI Module 1.3.2-SNAPSHOT Data Exchange Module 1.3.2 UI Library Module 2.0.4 Reference Demo Data Module 1.4.3
Hi Katrina,
I quickly tried to replicate the first error on demo.openmrs.org (openmrs-core 2.0.5 and reporting 1.12.0) but I could not. Can you try to replicate this there, or on qa-refapp.openmrs.org, so we can debug further?
Also, I see this:
OpenMRS Version 2.2.0 SNAPSHOT
Is there a specific reason you’re using a snapshot build of openmrs-core, instead of a (stable, supported) released version?
My attempts to replicate the error within the reference app haven’t been successful, however I will continue trying to do so. Regarding why a snapshot build is being used, I will have to ask our system adminstrator why that is the case.
My suggestion is:
- figure out if a snapshot is necessary (it’s not normally how people run OpenMRS), and if not, shift to openmrs-core 2.0.5 or 2.1.0.
- if this resolves the problem, then we’re find (but you should let @mseaton know about this in case something has happened in the latest core version that breaks the reporting module )
- if you need to run the snapshot, or if changing the openmrs-core version doesn’t fix the problem, then we can debug further.
Okay, good news, the problem has been fixed. I spoke with the system adminstrator, and she reported that the issue was, in her words, " It seems like the may 4th war was diff than the April 27th war. We were on may 4th, moved to April 27th. Allso compiled from scratch because may 4th was broke."
Not sure if that helps with identifying what the underlaying cause for the errors where, but all is working as intended now.
Thank you again for your time.
@kprosise, glad it’s working now!
Please pass along the message to your system administrator that:
- We do not recommend running a snapshot version of OpenMRS. These will include code that has not been thoroughly tested, might contain database changes that could be reverted, etc. You should run a released, supported version of the OpenMRS Platform.
- There is no need (or reason) to build OpenMRS from source. You can (and should) download a precompiled version from sourceforge. Go there via http://openmrs.org/download/
- The latest Platform release is 2.0.5. We recommend you use this.
@mseaton, FYI from this thread it’s possible that something between the April 27 and May 4 versions of openmrs-core breaks the reporting module.
@darius, hmm - odd that anything in core would do that and nothing really stands out in the commits listed during those dates in github (though I only skimmed them, and not sure if they represent reality at that time). Could there have been code introduced around the expanded Cohort / Cohort Membership stuff that is incompatible with the way Cohort is used in reporting?
Mike
It’s quite possible that we (accidentally?) broke backwards-compatibility of some Cohort method…
The reporting code for CompositionCohortDefinition isn’t totally straightforward to read when I peeked at it right now, but we should look into it.
-Darius