Please help us help you and fill where relevant:
Your LimeSurvey version: 6.5.6
Own server or LimeSurvey hosting: yes
==================

Hi, First: Thanks for sharing that cool tool with us!

Recently an user created a survey and wanted to publish it but got the error:

"CDbCommand konnte das SQL-Statement nicht ausführen: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.. The SQL statement executed was: CREATE TABLE `lime_survey_797438` ( .....

The survey has 135 questions .... so I guess thats to much for the table to be created with the "normal" db settings.

What might be a good solution to bypass that restriction or other suggestions are welcome to help solving that issue.

Thanks / Götz
 

P.S. the suggestions here might be helpfull but apply to an existing table or changing teh da systems behaviour (what I'd like to avoid!)

mariadb.com/kb/en/troubleshooting-row-si...-errors-with-innodb/
 

The number of possible columns depends on the database engine. There is some information about this in the manual:

www.limesurvey.org/manual/General_FAQ#MySQL_and_MariaDB

Own server or LimeSurvey hosting: yes

Not very helpful. You answer to the question if you run Limesurvey on your own server or if you are using hosting through the Limesurvey Gmbh (SaaS) with "yes". 

The solutions of your issue are:
1. Reduce the number of questions or subquestions (each subquestion receives one column). Given that you "only" have 135 questions (who is supposed to answer this?), you probably have a lot of subquestions in some of these questions, to run to into this database limit;
2. Another solution is to split the survey into two surveys and connect the surveys via END URL. This is of course not always possible, if you have conditions in the second survey that would depend on questions from the first survey. To a certain extend this can be solved by passing data in variables via the end URL, but of course this wouldn't work if there is a heavy reliance on this.

Hi and thanks for your feedback and suggestions.

So my thoughts haven't been that wrong regarding the amount of questions .... I'ts a students-organisation survey for all students and they try to cover all kind of different topics in one survey. We suggested to split it up in two or three surveys.

I also thought about using some mysql inodb options to create that table but I'm happy if i dont have to do that

Thanks once more and regards!