Hallo Zusammen!

ich habe jetzt meine erste große Umfrage mit LimeSurvey erstellt und war ganz begeistert! Alles funktioniert, die Vorschau läuft, Bedingungen, Matrix-Antworten etc. alles wunderbar.

Als ich die Umfrage jetzt allerdings aktivieren wollte bekomme ich folgenden Hinweis:

Die Umfrage-Antworttabelle konnte nicht erstellt werden. Üblicherweise wird dies durch zu viele (Teil-)Fragen in Ihrer Umfrage verursacht. Bitte versuchen Sie Fragen aus Ihrer Umfrage zu löschen.

Jetzt weis ich nicht was ich tun soll... Ich brauch die Umfrage genau so. Weis jemand wie diese Fehlermeldung zustande kommen kann ? Liegt es vielleicht nicht an der Größe der Umfrage sondern an Datenbankbeschränkungen oder ähnlichem ?

Über Hilfe würde ich mich sehr freuen... die Umfrage hat 79 Fragen in 12 Gruppen, wobei jeder User nur Maximal 5 Gruppen angezeigt bekommt, je nach Auswahl bei einer Frage. Und die meisten Fragen sind Matrixantworten mit 3x8 Fragestellungen...

Ich nutze Version 2.50.1+160823
PHP 5.6 latest
MySQL 5.5.53-0+deb8u1

Hallo, JasminSky,
da hat es Dich ja schön erwischt.
Gut, es ist bekannt - oder sollte es sein - dass es eine Kapazitätsobergrenze gibt, was die benötigten Spalten in der Antworttabelle angeht.
Also: Zähle mal, wieviele Spalten benötigt werden:
Pro Antwortmöglichkeit eine Spalte, wobei bei Mehrfachennungen natürlich jede Teilfrage eine eigene Spalte hat (dort steht nämlich "gewählt" bzw. "Nicht gewählt".
Und bei Matrixfragen ebenfalls.

Die genaue Obergrenze habe ich im Moment nicht parat, aber egal, Deine Studie wird als zu groß angemeckert.

Wenn die Auswahl der Gruppen wirklich an EINER Frage hängt, könntest Du z.B. die Umfrage teilen, so dass die End-Url der ersten Hälfte auf die zweite Hälfte verlinkt und Du an diese Url das Ergebnis der "Gruppenfrage" anhängst, damit sie auch im zweiten Teil wirksam ist.

Normalerweise würde ich sagen , dass - wenn die Matrixfragen aus drei Items und 8 Antwortmöglichketen bestehen (single punch) - dies nicht entscheidend ist.
Oder sind sie Mehrfachnennung?

Bis dann
Joffm

Hallo Joffm,

danke für die schnelle Antwort

Tja hm, ich hab auch nochmal in meinen Studien-Unterlagen gewühlt... die Info, dass MyISAM eine Column-Obergrenze hat, habe ich wohl irgendwann verworfen, weil ich nie gedacht hätte, dass ich da mal drauf stoßen würde.

Die Matrix Fragen sind tatsächlich Matrix-Text Fragen... heißt jede einzelne Frage öffnet 24 Spalten, also insgesamt 1680 Spalten bei 70 Fragen welche in der Datenbank als type "text" definiert werden... (9-12 bytes pro Spalte) heißt 15120 bis 20160 bytes pro Zeile... und dazu kommen noch die anderen Fragen... ich verstehe warum das zu lang ist.
(Ich will hier keinen hardcore Programmierer verärgern, wenn die Zahlen nicht stimmen, das ist das, was ich mit meinem brüchigen Wissen grad mal so errechnet hab. Bitte korrigieren wenn's nicht stimmt.)
Schade, dass LimeSurvey alle Antworten in einer Spalte speichert und nicht in einer Spalte pro Fragengruppe (Das würde das Problem komplett eliminieren)

Die Idee mit der URL-Weiterleitung klingt interessant, ich hab aber leider keinen Plan wie das geht... habs jetzt auf Anhieb auch nicht in der Dokumentation gefunden.. der Link beim Eintrag "End-Url" führt leider zu einer 404-Page...
Könntest du mir eventuell in einem kurzen Beispiel erklären wie das machbar ist, oder hast du nen funktionierenden Link wo das schon mal erklärt wurde ? Das wäre furchtbar nett

Viele Grüße
JasminSky

Hallo, Jamin,
okay, gut, das erste Problem ist erkannt; ehrlich gesagt, für Dich nicht gut.
Ich weiß nicht, ob man dies bei der Installation einstellen kann (wer merkt sich das schon?), aber meine Tabellen sind vom Typ "InnoDB".
Und laut MySQL-Manual:

Storage engines may impose additional restrictions that limit table column count. For example, InnoDB has a limit of 1017 columns per table.

Völlig egal, was Du ausgerechnet hast, weit über 1000 benötigte Variable - das war's dann.

Was die End-Url betrifft, das verstehe ich nicht. Also die sache mit dem Link und der 404 Seite.

In "Umfrage-Einstellungen" / "Generelle Einstellungen und Texte" findest Du unten das Feld "End-Url". Oder?
Und im Teil "Präsentation und Navigation" gibt es die Option "Automatisch Url laden..."

Deine Url könnte z.B. so aussehen:
" www.mylimesurveysurver.de/limesurvey/ind...test/Y/lang/de?z={Q1 }",
wobei "z={Q1} der angehängte GET-Parameter ist, der übergeben wird, hier mit dem Ergebnis der Frage Q1.
Den musst Du dann in dieser aufgerufenen Umfrage abfragen.

Und: "https://" ist unerlässlich; nicht nur " www.tralala.com "

Über diese Weiterleitung gibt es einige Threads hier im Forum. Ich persönlich habe mich damit aber noch nicht wirklich beschäftigt.

Viel Erfolg
Joffm

Hallo, Jasmin,
nur noch ein kleiner Zusatz.
Ich habe gerade im Manual Folgendes gefunden:

What limitations does LimeSurvey have...
...regarding speed

There is no existing speed limit on LimeSurvey. It all depends on how fast your server and your connection is. If you expect a large number of users within a short time and you are not sure if your server can handle this check our forum for according topics about other users' experience.
...regarding survey size

Note: 'Survey size' refers to the maximmum number of questions (and answers) in your survey - don't confuse this with the number of replies on your survey (there is no limitation on that). Theoretically there would also be no limit on the maximum number of questions/answers in LimeSurvey. But the database engine you are using has several limits. The most important one is the limit on the number of fields(columns) in the result table.

• MySQL ISAM: The sum of the lengths of the VARCHAR and CHAR columns in a table may be up to 64KB.
• MySQL InnoDB: Maximum number of 1000 columns
• MS SQL Server 2000: Maximum number of 1024 columns
• Postgres: Maximum number of 250-1600 columns depending on column types. The maximum number of columns can be quadrupled by increasing the default block size to 32k. See Installation FAQ and PostgreSQL FAQ.

Take care here: please think about what you do before you do it: an array of 10 x 10 items already costs you 100 columns. Rule of thumb: every item on the screen that can be filled in or selected costs one column!

The mySQL ISAM engine is the most tricky one (see mysql documentation for more information). As it allows only up to 65,535 bytes per row and utf8 characters can require up to three bytes per character the maximum may be only 21,844 characters (but this depends on your DB encoding).

You can roughly calculate the size of your survey like this:

• Every multiple numerical question: 20 chars for each answer
• Every multiple choice & array question answers: 5 chars for each answer
• Every other question type: 5 chars
• Add 10% for the usual overhead

Alles Gute
Joffm

JasminSky wrote: Die Idee mit der URL-Weiterleitung klingt interessant, ich hab aber leider keinen Plan wie das geht... habs jetzt auf Anhieb auch nicht in der Dokumentation gefunden..

Bevor Du die Idee mit der Aufteilung der Befragung auf zwei Teilumfragen angehst, solltest Du überprüfen, wo Du die Befragung teilst.
Da Du keinerlei Filter vom ersten im zweiten Teil ansprechen kannst, ohne diese händisch über Parameter weiterzureichen, solltest Du hier gut planen. Das ist aufwändig und fehleranfällig. Und vorher genau zu testen, weil sich hier kaum jemand für die Parameterübergabe interessiert. Z.B. gibt es in der Oberfläche eine Bug, so dass nicht mehr als 10 Parameter definiert werden können. Das ist seit 4-5 Wochen ungelöst laut Bugticket ( bugs.limesurvey.org/view.php?id=11636 ).

Für eine Mehrfachantwort ist es auch nicht ausreichend einen Parameter zu übergeben.

wobei "z={Q1} der angehängte GET-Parameter ist, der übergeben wird, hier mit dem Ergebnis der Frage Q1.

Das hier klappt bei einer Einfachfrage. Aber wie sollte ein Parameter eine Mehrfachfrage übertragen? Und wenn Du die Mehrfachbefragungen in einzelne Paramter zerlegt hast, musst Du die auch wieder für die Filterführung in der zweiten Befragung abgreifen. Auch bei einfachen Textantworten müsste der Text noch URLcodiert und recodiert werden.
Da unterstützt einen LimeSurvey nicht.
Fazit: Bei hintereinandergeschalteten Befragungen ist der Aufbau der Befragung so zu gestalten, um die Übertragung von Daten so klein wie möglich zu halten. Weitere Nachteile von hintereinander geschalteten Befragungen liegen in Befragtenhandling. Wenn Du eine geschlossene befragung hast, dann ist die Befragung nach dem ersten Teil fertig. Fliegt ein Befragter im zweiten Teil raus und versucht über den Link wieder reinzukommen, wird das abgelehnt, da die Befragung bereits "erfolgreich" abgeschlossen wurde.

Die Datenbankstruktur von LS ist schon verrückt. Aber Bridging von Befragungen in Limesurvey ist oftmals keine einfache Lösung.

Weil man nur wenig Links Posten darf, halt ein neuer Post. LS GmbH scheint ja dauerhaft an dieser SPAM-Schutzmaßnahme festhalten zu wollen. Erschwert die Antworten mit Beispiellinks enorm. Die Bots stört es nur einmal. Mich dauerhaft.

Wenn man sieht, was für Klimmzüge aufgrund der Datenbankstruktur versucht werden.
stackoverflow.com/questions/40289764/add...290716?noredirect=1#
Es gab auch mal ein Studentenprojekt 2010 dazu: www.limesurvey.org/manual/Database_Storage_Engine_Project

Zu den technischen Geschichten wurde ja schon einiges geschrieben. Ich frage mich halt wer 79 Matrix-Fragen ordentlich beantworten soll, vor allem wenn auch noch als Texteingabe. Nach der 5. Matrixfrage antwortet doch keiner mehr ernsthaft, oder?

holch wrote: Ich frage mich halt wer 79 Matrix-Fragen ordentlich beantworten soll, vor allem wenn auch noch als Texteingabe.

Gerade bei Limesurvey hast Du doch diverse Workarounds, welche x-faches Anlegen einer Frage notwendig machen.
Looping gibt es nicht. Dynamische Listen gibt es nicht. Es ist also nicht immer der Fall, dass viele Matrixfragen angezeigt werden.
Persönlich habe ich noch nie bei einer Befragung das technische Limit erreicht. Aber ich spüre auch körperlichen Schmerz, wenn ich eine Matrixfrage in LS anlege. Somit wächst die Spaltenzahl auch nicht so schnell an

Hallo, JasminSky

ich sehe, wir rutschen ein wenig in "generelle Erörterungen" ab.
Daher noch etwas zum Problem.
Nach den gegebenen Informationen scheinen die einzelnen Gruppen unabhängig voneinander zu sein. Das bedeutet für mich, dass es keine gruppenübergreifenden Filter, Bedingungen, etc. gibt.
Desweiteren soll die Auswahl der Gruppen an einer Frage hängen.
Sollte dies so richtig sein, kann man durchaus zwischend er sechsten und der siebten Gruppe trennen, und es genügt ein einziger Parameter.
Sei die "Auswahlfrage" eine Einfachnennungesfrage ist es banal. Bei allen anderen kann man sicherlich mithilfe einer Equation eine Kennzahl bestimmen.
Da es nun 63 Möglichkeiten gibt, aus diesen 6 Gruppen des zweiten Frageteils 0,1,2,3,4 oder 5 auszuwählen, genügt also diese Kennzahl zwischen 1 und 63.
Wie gesagt, ich benutze hier nur die bisherige Information.
Und dieses Verbinden der Studien per End-Url klappt ganz gut.

Da wir nicht wissen, welche Fragen in den verschiedenen Gruppen gestellt werden, ist es im Moment müßig, darüber zu spekulieren, ob man die Sache verkleinern kann, indem man nur eine (oder einige wenige) Gruppe(n) hat und einfach die Fragentexte mit Bedingungen anpasst.
Also das gute alte Beispiel "Sehr geehrte {if(Q1==1,'r Herr','Frau')} Müller"

Dazu solltest Du ein Beispiel schicken.

holch hat völlig Recht: 5 Gruppen mit im Schnitt 6 x 3x8=120 Texteingaben sind 600 Texte (gut, vielleicht nicht als Pflichteingabe).
Aber welcher Respondent ist schon so masochistisch, sich das anzutun?

Hinzu kommt das Problem der Auswertung bei diesem Wust an Texten. Je nach Fragestellung kann hier ganz schöner "Blödsinn" eingetragen werden.
Soll heißen: Wird hier z.B. nach einer Automarke gefragt (relativ begrenzter Antwortraum), oder etwa "Nennen Sie bitte Probleme beim letztjährigen Schützenumzug". Da wird es dann mit der Quantifizierbarkeit schwieriger. Es sei denn, die Umfrage dient nur im kleinen Rahmen als eine Art "Brainstorming".
Aber das wissen wir alle nicht.

Alles Gute
Joffm