1240+ columns can be fine, or they can't. Unfortunately there is no way to say that the limit is exactly X columns, without know the questions, etc. But Joffm gave you a very clear example. But it doesn't mean that 1575 is the limit in all cases.

How will you notice that you run into this limit? I think you will only really know once you activate the survey and then get an error message. Maybe Denis knows more.

holch wrote: How will you notice that you run into this limit? I think you will only really know once you activate the survey and then get an error message.

Correct. The amount of questions is often more than it looks. There is a reason why LimeSurvey has questiontypes with answers and sub-questions. Subquestions demand more space. A single answer question has answers. A multiple choice question has subquestions.

As long as LimeSurvey carries on with the "wrong" database concept (Roadmap states "Refactor answer database to get rid of column limitations"), you will hit the wall with the database depending on your survey design on the range of "never" to "quite often". Even with a "simple" survey design you can hit the database limit. If you think about workarounds for looping and other features, you get to the limit even quicker.

jelo wrote: As long as LimeSurvey carries on with the "wrong" database concept...

So, what would be the "right" design? Basically, I can only see two viable options here:

1. Seamlessly creating overflow tables when the row size limit is reached.
2. Having a single, very simple answer table with one row per answer and the columns being participant-token, survey-id, survey-instance-id, question-id, [subquestion-id] and, finally, the value, which would be just a bit-bucket of a certain length. The value field, of course, would need to be interpreted based on the question type whenever the results are either displayed or exported. This kind of an architecture would clearly be more performance-intensive than the current one, but we are not talking about mega transaction volumes here, so I think it would be doable, and on the positive side, it's a very simple solution, and one that takes care of the row size limit problem once and for all.

oleggorfinkel wrote: So, what would be the "right" design?

The typical design is distributed via different tables with a maptable.

Depending on additional features, you end up with a handful of tables.

To get an impression, take a look at this here:
www.sawtoothsoftware.com/help/lighthouse...d_web_howstored.html

Long answer code : bugs.limesurvey.org/view.php?id=7593#c52401

@ollehar open a mantis issue about separate database (in some condition)

I don't find it

jelo wrote:

oleggorfinkel wrote: So, what would be the "right" design?

The typical design is distributed via different tables with a maptable.

Depending on additional features, you end up with a handful of tables.

To get an impression, take a look at this here:
www.sawtoothsoftware.com/help/lighthouse...d_web_howstored.html

Yes, that's exactly what I was talking about as option #1 in my previous message.

I need to manually override the answer code length this for one of my surveys.

I see the table _answers has the column code varchar(5). I need to change this to varchar(.

When I change it, I see that LS still restricts the length to varchar(5), so I'm guessing somewhere in the LS codebase, the max length of _answers.code is defined?

Can anyone point me to the location where max length of 5 is defined, so I can override it to 8?

Digging a bit deeper into this, I've tested with these changes, and it appears to work:

/application/views/admin/survey/Question/subquestionsAndAnswers/_answer_option.twig : ln #53

/application/models/Answer.php : ln #75

/application/views/admin/labels/_labelviewtabcontent_view.php : ln #47

And update database columns:

ALTER TABLE `lime_answers` CHANGE `code` `code` VARCHAR(15) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';

ALTER TABLE `lime_labels` CHANGE `code` `code` VARCHAR(15) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '';