Hi Jason, did you resolve this..? Are you seeing any invalid indicator numerators or denominators when running integrity checks?
cheers Lars On Sun, Nov 3, 2013 at 5:07 AM, Jason Pickering <[email protected] > wrote: > Hi Lars, > > I am stuck with this once again on another database, upgrading to 2.13. I > have tried to clear out absolutely everything which I think might be > causing this, but it is being stubborn once again. > > Could you let me know all possible tables which might be contributing to > this error? > > Regards, > Jason > > > > On Mon, Oct 14, 2013 at 2:40 PM, Lars Helge Øverland > <[email protected]>wrote: > >> Hi Jason, >> >> you are right in that the relevant code is a bit optimistic when it comes >> to expression validity. >> >> Are you able to send me the database (without any data/sensitive stuff) >> in its invalid state? The weird thing is that this is not being picked up >> in the integrity checks. Will be useful to see what kind of corner case is >> causing this. >> >> cheers >> >> Lars >> >> >> >> On Fri, Oct 11, 2013 at 4:14 PM, Jason Pickering < >> [email protected]> wrote: >> >>> I think I have managed to get to the bottom of this. I believe there is >>> a weakness in the explodeExpression method, which causes this NPE when >>> there are invalid expressions present in the system. Version 2.10 seemed to >>> be rather tolerant of this but wit the change to UIDs in expressions, some >>> of the "invalid" expressions were not being upgraded, which I noticed in >>> the logs. After the ugprade to 2.12 (from 2.10), there were a large number >>> of expressions which were invalid. >>> >>> 1) Blank expressions. These very likely were from our original import >>> from 1.4, and have been there all along, but never really been detected. >>> 2) Invalid expressions which were unable to be upgraded.These were all >>> the ones which did not have UIDs in them . >>> >>> I was not exactly sure (am still not am) what the implications of >>> removing these were. In some cases, I got a key violation >>> with expressiondataelement and I removed these as well. After all of that >>> witchcraft, I started up the system again, and it worked. >>> >>> I think the explodeExpression method is expecting valid expressions, but >>> these were not being picked up in the integrity checks for some reason and >>> ends up throwing this exception which prevents the download of metadata >>> during data entry. >>> >>> Regards, >>> Jason >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Oct 11, 2013 at 11:01 AM, Jason Pickering < >>> [email protected]> wrote: >>> >>>> Hi Lars/Devs, >>>> >>>> I am experiencing exactly the same issue after upgrading a 2.10 >>>> database to 2.12. Ran integrity checks, and there were no invalid >>>> indicators. >>>> >>>> This only seems to happen when the data entry page is loaded. >>>> Strangely, if I have a cached set of forms on my system, I do not get this >>>> error. >>>> >>>> Really need to figure out what may be causing this. :-/ >>>> >>>> Regards, >>>> Jason >>>> >>>> >>>> >>>> On Fri, Aug 23, 2013 at 12:52 PM, Lars Helge Øverland < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> can you please tell us which dhis version / build? >>>>> >>>>> This is likely to be caused by invalid indicator expressions. Can you >>>>> please run the integrity checks (in data administration -> integrity >>>>> checks) and look for invalid numerators and denominators? >>>>> >>>>> regards, >>>>> >>>>> Lars >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
