Tammo, the database limit problem has been a topic for a LOOONGG time now. You are not the first one to experience that and you probably won't be the last.
However, it was always considered a "niche" problem and there were no real plans on solving that.
I don't think it can be that problematic to simply start a new table and connect those two tables via the survey ID. But then I am no coder. I feel that this is a limitation of Limesurvey and from time to time some user runs into this limit.
Not a problem for a standard quick survey, but as soon as you have long item batteries with multiple choice you definitely get to that limit quickly. I hope LS 3.0 has some kind of better database concept for this.
Help us to help you!
Provide your LS version and where it is installed (own server, uni/employer, SaaS hosting, etc.).
Always provide a LSS file (not LSQ or LSG).
Note: I answer at this forum in my spare time, I'm not a LimeSurvey GmbH employee.
By the way, I am not a fan of long surveys. But my expierence in the forum shows, that there are many other applications Limesurvey is used for (clinical trials, scientific tests, etc.) where long questionnaires seem to be very common.
Help us to help you!
Provide your LS version and where it is installed (own server, uni/employer, SaaS hosting, etc.).
Always provide a LSS file (not LSQ or LSG).
Note: I answer at this forum in my spare time, I'm not a LimeSurvey GmbH employee.
In fact, I hate & detest long surveys my self. But my clients do not. Sometimes they need it for datacollection in which very large arrays are used like a spreadsheet. And these are repeated in the survey.
You will run into problems easily then.
We looked at slicing up the survey into several others, but since time was pressing, we reverted to plain old PHP for this time. The project was a repeat of an earlier project, we could partly re-use the code. But for shorter surveys we definitely prefer LimeSurvey.
Tammo ter Hark at Respondage
For Limesurvey reporting, education and customized themes
respondage.nl
holch wrote: Not a problem for a standard quick survey, but as soon as you have long item batteries with multiple choice you definitely get to that limit quickly. I hope LS 3.0 has some kind of better database concept for this.
Limesurvey 3 uses a far more modular code which should allow a different data storage. I'll ask the LS 3 core dev to add some more details.
Best regards/Beste Grüße,
Dr. Marcel Minke
survey-consulting.com
offlinesurveys.com
Feel free to contact me by email for professional LimeSurvey support!
While LS3 is a lot more modular and could support another storage method, it does not do that yet.
In most cases the column limit is only relevant when using multiple choice question / array questions since they suffer from column explosion.
While alternative storage backends might solve the problem for survey taking also, very likely, remove all support for running statistical analysis inside LS for those kinds of surveys.
I just ran into this problem myself. Array (numbers) is not something I like to use and I most of the time talk clients into using something else but sometimes that is not possible, so here I am stuck with 6 Array (numbers) questions, each with 8 columns and around 60 sub questions (they will be conditioned so each respondent "only" gets to answer around 20 sub questions for each questions), not to mention the style is dropdown list which is really time consuming filling out.
So, from here I have two options (as I can think of):
* Split every array (numbers) question into one survey each and pre populate hidden questions with end URL to get conditions to work.
* Convince the client NOT to use "array (numbers)" as a question type.
Is there any more options?
Also, I would like to point out that, creating a survey with a HUGE SQL-table with lots of columns will affect your limesurvey installation, it will be getting slower to request.
