Hallo,

ich habe ein Problem mit meiner bereits gestarteten Umfrage (LimeSruvey Version 3.22.:

Ich hatte eine Umfrage mit geschlossenem Teilnehmerkreis gestartet. Dabei trat das Problem auf, dass die Probanden die Umfrage nachdem sie sie starteten, an einem anderen Tag nicht mehr fortsetzen konnten. Ich identifizierte das Problem in der Speicherung der IP Adresse meiner Umfrage. Daraufhin deaktivierte ich die Umfrage, deaktivierte das Speichern der IP Adresse, aktivierte die Umfrage wieder, lud die Teilnehmerdaten wieder rein sowie die Antwortdateien.

Seitdem klappt es, dass die Probanden, wenn sie eine Umfrage starten, diese auch an einem anderen Tag fortführen können. Dies klappt aber nur für neue Teilnehmer, die die Umfrage also nach meinem Problemlösversuch starten. Diese können die Umfrage dann ohne Probleme später (an einem anderen Tag) fortführen.

Leider funktioniert dies nicht für all diejenigen, die die Umfrage vor meinem Problemlöseversuch starteten und nun fortführen wollen. Wenn der Proband über den Umfragelink die Umfrage öffnen möchte, seinen Token eingibt, erscheint leider ein weißer Bildschirm, der ihn daran hindert, die Umfrage zu beenden. Anders sieht es aus, wenn ich selbst die Umfrage über meine LimeSurvey Umfrage heraus starte (über den Button "Umfrage ausführen"). Wenn ich die Umfrage damit öffne, einen Token eingebe, mit dem bereits die Umfrage gestartet wurde, kann ich die Umfrage an jener Stelle fortführen, wo der Proband eine Pause einlegte. Mein Problem dabei ist nun, dass ich den Probanden nicht meinen LimeSurvey Zugang nennen möchte, sodass diese die Umfrage daraus öffnen und fortführen. Über den Link jedoch, lässt sich die Umfrage leider nicht fortführen.

Ich versuche also zurzeit eine Lösung zu finden, wie ich allen Probanden ermöglichen kann, ihre Umfrage zu beenden, die diese schon starteten.

Ich wäre über jeden Lösungsansatz sehr froh und würde mich freuen.

Viele Grüße

Also, in solchen Dingen bin ich pragmatisch.

Wieviele sind es denn, die meinten, die Umfrage später weiterführen zu wollen?
Schick Ihnen einfach einen neuen Link, mit neuem Token,
entschuldige Dich, dass sich ein kleiner Fehler eingeschlichen hatte,
dass es Dir furchtbar Leid tut, dass Sie die Umfrage wieder von vorne machen müssen.

Joffm

P.S. Wie Du es anderweitig hinbekommst, im Moment keine Ahnung.
Geht es, die gespeicherte IP-Adresse dieser Teilnehmer aus den Daten zu löschen?
Und was passiert dann?
Mach Dir doch einmal ein kleines Beispiel, in welchem Du es probierst.
Also: Mit IP-Adresse aktivieren, einen Teil eingeben, dann unterbrechen, ...

Vielen Dank für die schnelle Rückmeldung!

Leider sind es um die 100 Teilnehmer, die auf dieses Problem stießen und immer wieder versuchten, die Umfrage zu beenden, jedoch scheiterten. Die Umfrage ist leider recht umfangreich und komplex und würde eine Datenverzerrung verursachen, wenn der gleiche Proband die Umfrage erneut durchführt (Lerneffekt).

Das mit dem Löschen der IP-Adresse in den Antworten habe ich hinbekommen. Das funktionierte, sodass die bereits gestarteten Umfragen, diese Spalte nicht mehr besitzen. Vermutlich konnte ich auch dadurch mit den Token die Umfrage von meinem LimeSurvey auch öffnen und hätte weiterführen können. Aber leider funktioniert es nicht, wenn der Teilnehmer es von zuhause über den Link macht.

Hab trotzdem vielen Dank für die Rückmeldung!

Aber, es ist, wie es ist.
Du hast die Wahl:
Verzichte auf diese Fälle.
Nimm die incompletes dieser Fälle (besser als nichts, würde mir aber Bauchschmerzen machen)
Lass es sie wirklich noch einmal machen.

Und den Lerneffekt haben beide dann , die Respondenten und Du auch.

Da ich aber den Einfluss der IP-Adresse noch nicht so sehe,
habe ich mir dieses Szenario einmal hingebaut.
Jetzt müssen wir aber wohl bis morgen warten, um einen Effekt zu sehen.

Bis dann
Joffm

Hmmm, dass die Speicherung der IP-Adresse das Problem verursachen soll, finde ich auch recht komisch. Denn da wird ja eigentlich nur ein Wert in der Datenbank eingetragen und dann nicht mehr abgefragt, soweit ich das weiss. Wenn das Problem aber wirklich daran liegt (was ich mir zwar nicht vorstellen kann), dann muss das auf jeden Fall als Bug gemeldet werden. Denn es kann ja durchaus sein, dass sich die IP-Adresse des Teilnehmers ändert.

Das Problem hört sich sehr seltsam an.

chemiesurvey20 wrote: Das mit dem Löschen der IP-Adresse in den Antworten habe ich hinbekommen.

Ich tippe mal darauf, dass durch die Veränderung des Datensatzes (hier IP-Adresse entfernt) sich noch etwas anderes im Datensatz verändert hat.

Die direkte Verbindung zur IP-Adresse kann ich auch nicht erkennen.

Die Version 3.22.8 hat aber bereits diverse Updates erfahren.

Da gab es z.B. eine Problem bei Token und Submit-Events.
bugs.limesurvey.org/view.php?id=15973
Ich kann keinen direkten Zusammenhang zur Fehlerbeschreibung hier herleiten, aber vielleicht gibt es einen.

Falls der Fehler sich mit 3.22.14+200423 reproduzieren lässt, ist ein Bugreport notwendig.

Vielen Dank für den schnellen Input und die Ideen bzgl. des Problems.

Ich wollte hiermit kurz beschreiben, wie ich mit dem Problem nun umgegangen bin, falls auch andere darauf stoßen und eine Idee haben wollen.

Ich dachte ja erst, es lege an der Speicherung der IP Adresse, aber das scheint nicht die Ursache gewesen zu sein, wie auch im Forum angesprochen wurde.

Endgültig konnte ich das Problem leider nicht beheben, aber ich habe herausgefunden, dass die Umfrage immer an einer spezifischen Stelle aussteigt und auch nur dann, wenn der Proband die Umfrage schließt (Browserfenster) und dann wieder öffnet. Er konnte dann nur bis zu dieser einen Stelle fortfahren und konnte die Umfrage dann nicht weiter bearbeiten. In der Umfrage habe ich randomisiert angeordnete Fragengruppen, die immer nur zu einer bestimmten Bedingung angezeigt werden (Relevanzgleichung - anhand einer gezogenen Ziffer in einer versteckten Frage). Gemäß dessen werden dem Probanden dann Aufgaben aus einem Pool in randomisierter Reihenfolge gezeigt. Genau an dieser Stelle steigt die Umfrage leider bei zuvorigem Schließen und dann wieder Öffnen aus.

"Behoben" habe ich das Problem nun, indem ich eine separate Umfrage generierte, die mit der Originalumfrage identisch ist, nur, dass sie die Fragengruppen vor den randomisierten nicht mehr besitzt. Das heißt der Proband kann dann einfach in die 2. Umfrage wechseln und kann dort die Umfrage beenden. Dabei kann es zu Aufgabendopplungen kommen, aber besser als nichts. Den Link zu dieser 2. Umfrage habe ich in die bestehende Umfrage eingebaut mit dem Hinweis, dass dieser zu betätigen ist, sollte die Umfrage sich nicht weiter fortführen lassen.

Das ist die Idee, wie ich mit dem Problem umging, auch wenn ich leider nicht genau herausfinden konnte, worin das Problem begründet liegt. Vielleicht kann die zufällig gezogene Ziffer nach Schließen der Umfrage und dann wieder Öffnen nicht mehr abgerufen werden, sodass dann nicht klar ist, welche Fragengruppen präsentiert werden sollen.

Ich hoffe, falls bei jemand anderem ein ähnliches Problem auftritt, dass er von meinem Lösungsweg bzw. Umgang mit dem Problem profitieren kann.

Beste Grüße

Übrigens,
ich hatte ja versprochen, das Szenario einmal durchzuspielen.
Und wie erwartet, habe ich kein Problem gefunden, egal ob mit neuer IP-Adresse (am nächsten Tag) auf derselben Maschine fortgesetzt wurde, oder auf einem völlig anderen Rechner.

Das ist die Idee, wie ich mit dem Problem umging, auch wenn ich leider nicht genau herausfinden konnte, worin das Problem begründet liegt. Vielleicht kann die zufällig gezogene Ziffer nach Schließen der Umfrage und dann wieder Öffnen nicht mehr abgerufen werden, sodass dann nicht klar ist, welche Fragengruppen präsentiert werden sollen.

Das ist doch schon etwas, was man näher untersuchen kann.

Auch kennen wir leider Deine Umfrage nicht. Hänge doch einmal den lss export an.

Joffm

Entschuldigt für die späte Antwort. Die lss-Datei der Umfrage darf ich leider nicht anhängen, aber ich kann kurz beschreiben, wie die Umfrage aufgebaut ist:

Versteckte Frage (F): Gleichung, Rand{(1,10)}

Fragengruppen 1-10: allgemeinen Fragen (Demographische Daten etc.), diese werden allen Teilnehmern gezeigt

Fragengruppe 11: hierbei sind 90 Fragen hinterlegt; dabei ist in jeder Frage in der Relevanzgleichung hinterlegt, bei welcher Ziffer aus der versteckten Frage sie angezeigt wird; bspw. F == 1 or F == 2; zudem sind alle 90 Fragen in der gleichen Randomisierungsgruppe (R)

Fragengruppen 12-16: allgemeinen Fragen, auch diese werden dann nach der Frauengruppe 11 allen Teilnehmern gezeigt

Beste Grüße

aber ich kann kurz beschreiben, wie die Umfrage aufgebaut ist:

Das hilft natürlich nicht viel. Denn wir sehen ja nicht, was du wirklich gemacht hast. In unserem Kopf machen wir das natürlich alles richtig. in der Praxis sieht es aber eventuell anders aus.

Aber: ich hoffe deine Gleichung sieht nicht so aus, wie du sie gepostet hast:
Sonder in etwa so, mit "randnumber" als Code für die Gleichungsfrage die die Zufallszahl erzeugt:

Kurze Rückfrage zu der Rand-Funktion: Ehrlich gesagt, dachte ich, dass sie für die Ziehung einer Zahl von 1-10 gut funktioniert.
Ist das zu unsauber und man sollte lieber den von dir vorgeschlagenen Code verwenden? Ich kenne mich dahingehend leider nicht tiefer aus. Daher diese Rückfrage.

Hallo,
was meinst Du mit "unsauber"?
Ich würde eher sagen, unsicher.

Das Problem ist ganz einfach.
Wie z.B. auch bei EXCEL liefert die Funktion "rand(1,2)" bei jedem Seitenaufruf eine neue Zufallszahl.
Probiere es in EXCEL einfach einmal aus. In einer Spalte ein paarmal die Funktion "=ZUFALLSZAHL()", und dann gibst Du in einer anderen Spalte ein paar Zahlen ein.

Dies kann passieren, wenn der Respondent zurückgeht und wieder über die Seite der Generierung kommt.
Dies kann passieren, wenn man "Gruppe für Gruppe" anzeigt; wenn dann Zufallszahlerzeugung und weitere Fragen in der Gruppe sind, wird diese bei jeder Beantwortung einer Frage geändert. Ganz schlimm kann sich dies auswirken, wenn Du diese Zahl in derselben Gruppe auch noch verwendest.

Um dies zu verhindern, benutzen wir dieses IF-Konstrukt.
Ich hoffe, Du weißt, wie die IF-Funktion funktioniert - IF(Bedingung, was wenn WAHR,was wenn FALSCH))
"{if(is_empty(randnumber.NAOK),rand(1,2),randnumber.NAOK)}"
Das heißt ja nichts weiter wie
WENN( Ist die Zufallszahl noch leer?, JA: DANN erzeuge eine Zufallszahl zwischen 1 und 2, NEIN: DANN bleibt sie wie sie ist)

Und das NAOK dient dazu, in bestimmten Funktionen auch nicht existierende Werte zu berücksichtigen.
Das steht aber alles im Handbuch.

Aber wie holch schon schrieb: Das nützt alles nichts, theoretisch mag ja alles beschrieben sein; und trotzdem hast Du irgendwo einen kleinen Fehler eingebaut.
Da nützt wirklich nur der lss Export; sonst können wir auch nicht helfen. Dann ist vieles in den blauen Dunst gesprochen.
Und wir sind wirklich nicht am Abgreifen irgendwelcher Umfragen interessiert; daher solltest Du Deine Originalstudie kopieren, und dann kannst Du auch alle Texte durch Blindtexte ersetzen.


Joffm

Kurze Rückfrage zu der Rand-Funktion: Ehrlich gesagt, dachte ich, dass sie für die Ziehung einer Zahl von 1-10 gut funktioniert.

Ja, rand(1-10) wird dir schon schön brav Zufallszahlen ausspucken. Das ist nicht das Problem.

Ist das zu unsauber und man sollte lieber den von dir vorgeschlagenen Code verwenden?

Du solltest auf jedenfall meinen Code verwenden, deswegen habe ich ihn ja gepostet. Dein Code ist nicht falsch, er wird eine Zufallszahl erzeugen. Immer, wenn er aufgerufen wird. Das kann in der gleichen Umfrage ja mehrmals passieren und das will man aber in den seltensten Fällen.

Normalerweise will man, dass die Zufallszahl einmal gezogen wird, und dann fest bleibt. Mit deinem Konstrukt kann kann es aber sein, dass ich diese Zufallszahl im Laufe der Umfrage ändert.

Joffm hat ja alles schon schön erklärt.

Ich kenne die Struktur deiner Umfrage nicht, aber ich kann mir schon gut vorstellen, dass eventuell dieser Code dafür sorgt, dass es beim Wiedereinstieg Probleme gibt.

Habt vielen Dank für Euren Input! Das mit der If-Funktion für die Ziehung der Zufallszahlen hatte ich nicht auf dem Schirm und hatte mich da der Rand-Funktion bedient. Danke!

Das mit der If-Funktion für die Ziehung der Zufallszahlen hatte ich nicht auf dem Schirm und hatte mich da der Rand-Funktion bedient.

Du bedienst dich ja weiterhin der Rand-Funktion, halt jetzt nur "abgesichert" durch ein IF, um zu garantieren, dass die Zufallszahl nur einmal erzeugt wird, und nicht jedesmal neu ausgewürfelt wird, wenn auf die Equation-Frage zugegriffen wird.