Urgent: Running Analytics - Process failed Month not valid [1,4,7,10] was given 6

Support - Assistance technique
1

Hi Dhis2 Community,

I’m re-posting this question again after 3 days, b/c no one have responded yet.

I have a problem while running analytics after entering data in an offline version (local host) of Dhis 2 version 2.28 for aggregate data. The error message reads as follows:

“Process failed Month not valid [1,4,7,10] was given 6.”

The screen shot of the error message is attached in the message below.

I look forward to your support.

With best wishes,
Michael

2

Hello Michael,

The screenshot is not attached. And can you post more detailed information on the version of the WAR file you are using.

Thank you.

3

Hi Michael,

this issue should be fixed in later versions. Please upgrade to a supported version of DHIS 2 meaning 2.31.8 or later and try again.

best,

Lars

4

Selam Melake,

Thank you for your reply and support. Attached within is the screenshot.

The War file I’m currently using is for version 2.28 which is downloaded and updated in mid 2019 (it’s not the most recent one). So your question leads to one possible solution- to update the latest war file for version 2.28. Thanks again.

With best wishes,
Michael

Process failed Month not valid 1 4 7 10 was given 6.docx (134.1 KB)

6

Hi Lars,

Thank you for your reply and support. I can’t simply upgrade to 2.31.8, because the national server is using version 2.28 and I think it better to use the same version through out the country for compatipility issue.

With Best Wishes,
Michael

7

Hi Michael

I’m facing the same error java.lang.IllegalArgumentException: Month not valid [1,4,7,10], was given 12 when running analytics. Im running DHIS2
2.31.10-SNAPSHOT with postgresql 10 on ubuntu 20.4. Attached is the logs screenshot.

image
image1910×1008 264 KB

8

Good day I am facing the same issue. I am using DHIS 2.36.13.2. What could be the issue really. We cant just upgrade. The users wants to have their reports as of now. So there no time for upgrading. Please assist.

9

Hi @tshidi.moroma
It looks like you have an invalid quarterly period in your system. What are the results of this query?


SELECT periodid,startdate,enddate,extract(month from startdate) from period where periodtypeid = (SELECT periodtypeid from periodtype where name = 'Quarterly') AND (extract(month from startdate) NOT IN (1,4,7,10));

Best regards,
Jason

10

Hi @jason
Here are the results,
11763950 “2030-12-10” “2031-03-09” 12
11763949 “2031-03-10” “2031-06-07” 3
11763948 “2031-06-08” “2031-09-05” 6

11

Ah, ok. Then I think you are going to need to try and get those periods out of your system since clearly they are not quarterly. Quarters should start on the first day of the month in months 1,4,7,10 and those do not, which is leading to that error.

Best regards,
Jason

12

Thank you so much @jason. I am doing that those the script takes too long to execute. But what could be the cause of this?

13

@tshidi.moroma likely this is due to the foreign key constraints on the period table.

What is too long? Like the query times out?

Can you check and see if you have any data in the datavalue table which are associated with these periods?

14

No entries in the datavalue table but the script is still taking too long

15

OK. I am not sure what taking too long means. Does the query time out?

The issue is that the period table has foreign key references to many other tables.

Referenced by:

    TABLE "lockedperiods" CONSTRAINT "fk8ef170885988b7d0" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "dataapproval" CONSTRAINT "fk_dataapproval_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "dataapprovalaudit" CONSTRAINT "fk_dataapprovalaudit_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "datainputperiod" CONSTRAINT "fk_datainputperiod_period" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "datasetopenperiods" CONSTRAINT "fk_dataset_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "completedatasetregistration" CONSTRAINT "fk_datasetcompleteregistration_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "datavalue" CONSTRAINT "fk_datavalue_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "datavalueaudit" CONSTRAINT "fk_datavalueaudit_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "eventvisualization_periods" CONSTRAINT "fk_evisualization_periods_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "interpretation" CONSTRAINT "fk_interpretation_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "lockexception" CONSTRAINT "fk_lockexception_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "mapview_periods" CONSTRAINT "fk_mapview_periods_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "validationresult" CONSTRAINT "fk_validationresult_period" FOREIGN KEY (periodid) REFERENCES period(periodid)
    TABLE "visualization_periods" CONSTRAINT "fk_visualization_periods_periodid" FOREIGN KEY (periodid) REFERENCES period(periodid)

So I think you would need to go through each of those tables one by one, and see if those periods exist in any of them. If so, you will need to deal with removing the records or reassigning them to another valid period.

After that, you can proceed to remove the foreign key references to the period table. This is obviously something you want to be extremely careful with, and not do on a live server. I suspect that the query is taking a long time because of the size of either your data value table or the datavalueaudit table. Since there are foreign key references to the period table, those tables have to be scanned to be sure that the period does not exist. But, if you have checked all of the tables above, and there are no references, then by removing the foreign key reference temporarily from the datavalue table, the operation to remove the faulty periods should be quick.

Once again, you should absolutely not perform this on your production database until you have thoroughly tested the approach!

Best regards,
Jason

1 Like