We have a form which when pulled from aggregate, works very fine for the
first iteration on the app via FILL BLANK FORM till the end. However, it
starts giving error when we try to do the 2nd iteration via FILL THE BLANK
FORM. This is pretty weird, since if there is some code issue in the form,
it should be evident in the first cycle of filling the form too. But it
only comes in 2nd iteration onwards.
My question: Is it possible for the stored-not-yet-sent data to cause issue
on the running form being filled?
I have the XML code file if someone wants to run a test and figure out a
solution.
It may be a "stack overflow" due to a very long expression in your
relevance, constraint, or calculation columns. See, Collect loads forms
from the original XML (slowly) the first time, then loads from a serialized
representation (more quickly) all subsequent times. When loading from the
serialized representation, it is susceptible to stack-overflow errors when
expressions are lengthy. To verify, you can remove any ultra-long
expressions and retry.
If you're using ODK Collect, you likely need to shorten your expressions
(e.g., by splitting them up into multiple calculation fields). If you're
using SurveyCTO Collect, you can request an upgrade since our latest
version will fall back automatically to the slower loading when required by
the form (but, if you want a quick form load, you should still shorten your
expressions).
Best,
Chris
···
On Mon, Sep 8, 2014 at 4:49 AM, Saad wrote:
Hi,
I am facing a strange issue.
We have a form which when pulled from aggregate, works very fine for the
first iteration on the app via FILL BLANK FORM till the end. However, it
starts giving error when we try to do the 2nd iteration via FILL THE BLANK
FORM. This is pretty weird, since if there is some code issue in the form,
it should be evident in the first cycle of filling the form too. But it
only comes in 2nd iteration onwards.
My question: Is it possible for the stored-not-yet-sent data to cause
issue on the running form being filled?
I have the XML code file if someone wants to run a test and figure out a
solution.
Which version of android are you running? Stock or custom Rom?
Thanks and Regards
Ronald Munjoma
···
On 8 Sep 2014 10:49, "Saad" wrote:
Hi,
I am facing a strange issue.
We have a form which when pulled from aggregate, works very fine for the
first iteration on the app via FILL BLANK FORM till the end. However, it
starts giving error when we try to do the 2nd iteration via FILL THE BLANK
FORM. This is pretty weird, since if there is some code issue in the form,
it should be evident in the first cycle of filling the form too. But it
only comes in 2nd iteration onwards.
My question: Is it possible for the stored-not-yet-sent data to cause
issue on the running form being filled?
I have the XML code file if someone wants to run a test and figure out a
solution.
It may be a "stack overflow" due to a very long expression in your
relevance, constraint, or calculation columns. See, Collect loads forms from
the original XML (slowly) the first time, then loads from a serialized
representation (more quickly) all subsequent times. When loading from the
serialized representation, it is susceptible to stack-overflow errors when
expressions are lengthy. To verify, you can remove any ultra-long
expressions and retry.
If you're using ODK Collect, you likely need to shorten your expressions
(e.g., by splitting them up into multiple calculation fields). If you're
using SurveyCTO Collect, you can request an upgrade since our latest version
will fall back automatically to the slower loading when required by the form
(but, if you want a quick form load, you should still shorten your
expressions).
We have a form which when pulled from aggregate, works very fine for the
first iteration on the app via FILL BLANK FORM till the end. However, it
starts giving error when we try to do the 2nd iteration via FILL THE BLANK
FORM. This is pretty weird, since if there is some code issue in the form,
it should be evident in the first cycle of filling the form too. But it only
comes in 2nd iteration onwards.
My question: Is it possible for the stored-not-yet-sent data to cause
issue on the running form being filled?
I have the XML code file if someone wants to run a test and figure out a
solution.
Yep, nothing more clever than that! It looked difficult to fix the root
cause and our poor users had seen one too many of these errors. It also
pops up a screen while loading to explain that they can speed it up by
shortening expressions.
Best,
Chris
···
On Sep 8, 2014 8:36 AM, "Yaw Anokwa" wrote:
Chris,
I'm curious how do you do the fallback? Do you catch the exception and
retry with the XML or do you have something more clever?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
It may be a "stack overflow" due to a very long expression in your
relevance, constraint, or calculation columns. See, Collect loads forms
from
the original XML (slowly) the first time, then loads from a serialized
representation (more quickly) all subsequent times. When loading from the
serialized representation, it is susceptible to stack-overflow errors
when
expressions are lengthy. To verify, you can remove any ultra-long
expressions and retry.
If you're using ODK Collect, you likely need to shorten your expressions
(e.g., by splitting them up into multiple calculation fields). If you're
using SurveyCTO Collect, you can request an upgrade since our latest
version
will fall back automatically to the slower loading when required by the
form
(but, if you want a quick form load, you should still shorten your
expressions).
We have a form which when pulled from aggregate, works very fine for the
first iteration on the app via FILL BLANK FORM till the end. However, it
starts giving error when we try to do the 2nd iteration via FILL THE
BLANK
FORM. This is pretty weird, since if there is some code issue in the
form,
it should be evident in the first cycle of filling the form too. But it
only
comes in 2nd iteration onwards.
My question: Is it possible for the stored-not-yet-sent data to cause
issue on the running form being filled?
I have the XML code file if someone wants to run a test and figure out a
solution.