I recently fell into the pit of desiging a very large survey, without looking at the limitations. This became very frustrating, since after more than a day of defining questions, I found out that the survey had become too large. That is: the answers table had too many columns and the survey could not run.

At that time I did not have time to dive into the possibilities of linking surveys, but now I have. I started to write an article (for the documenation) about this, which I want to share and discuss here. After discussing, hopefully with some usefull additions by YOU, my dear reader, I will publish it in the documenation wiki of LimeSurvey.

You can find the stub at:
docs.google.com/document/d/1J4dCuS2Egxv4...ZfQ/edit?usp=sharing

Please look at it and add you comments, edits, additions. Don't be afraid, Google docs is defined thus, that errors in writing can be easily deleted. With your help and with help from others we can make this rock!

Thanks in advance,

Tammo ter Hark

PS: the linked surveys that are attached as files to this forum artcle, have been provided by user Deusdeorum. Thanks to him I got started on this article.

tammo wrote: At that time I did not have time to dive into the possibilities of linking surveys, but now I have. I started to write an article (for the documenation) about this, which I want to share and discuss here.

Do you really see linking as a way to cope with the "unusual" database design for a survey system?
If big surveys would be top priority, we would see signs to get rid of the "unusual" database design now.
Even LS 3.0 will keep the "unusual" database design.
If linking/bridging surveys would be a top priority we would have seen some improvements in that area till today.

Linking / Bridging surveys are adding a lot of problems.

1. The survey design on paper has to be completely different.
Why? When linking surveys you cannot access all questions via conditions / EM.
You need to create proxy variables which all needs to put via GET parameters.
It is very difficult handle e.g. open text fields or arrays which needs to get converted to get transferred from one survey to another. So you have to minimize the amount of data which needs to be exchange between the survey parts. Which means changing the order of questions. Even then you end up with a lot of extra handling of variables.

2. Issues with sessions/tokens
Having more than one survey linked, bring up new issues with granted things.
E.g. when using tokens, a respondent cannot enter the survey again after finishing the first survey.
The link from the invitation is for the first survey. If the respondent gets lost in the second survey, there is no way to enter again. At least if you want to want to prevent to fill-out again the first survey.

Limesurvey is also big when it comes to session files. You end up with more space for sessions files as well.

You no longer can ensure that people can click a button to delete all given answers and leave the survey.
People are not able to go back from the second survey to the first one. You need to disable backward button at all or you end up with just one page without a backwards button.

3. Design issues
You need to tune things like progress-bar to ensure that you're not starting in the middle of the surveys at 0% again.
You need to change the submit button at the end of the first survey to next page.

Bridging surveys : Progress Bar Settings and no submit-button
bugs.limesurvey.org/view.php?id=9677
For the LTS version there is a workaround for the progress-bar tuning in that feature request ticket as well.

Your effort explaining the URL GET parameter handling will bring users to experience the bigger issues around linking surveys. Thanks for writing a more accessible manual section.

Question: Why do you want to assign external variables to equations? I see no difference to short text as a place to save things. In the past I had issues assigning values to number fields. From reading your text that seems to have changed. I no longer use LS that often, so I haven't check it by myself.

I never experienced issues with big surveys but I often needed to integrate a third party survey inside a LS survey. So I often ended up with three surveys linked together. Depending on the survey design the amount of additional work was amazing.
If you need to link surveys because one survey is too big you might need to add lot more proxy variables then I can imagine.

I have high hopes regarding the online marketing manager position.
One task is "Competition monitoring and analysis" which means that LS GmbH has to define the userbase and their demands. Which will reduce the amount of discussion around what user really need or not.
If the main competitor is SurveyMonkey, users will expect limits in this range:
help.surveymonkey.com/articles/en_US/kb/...-or-character-limits

Hi jelo,

thanks for your elaborate answers, which is actually telling me that what I am doing is:

1. not worth the trouble, because paper surveys will run in a lot of trouble
2. not worth the trouble, because it is rarely used (if it were really necessary the database design would have been changed)
3. very difficult
4. will lead innocent users in many other problems

You even say: Thanks for writing a more accessible manual section. (Is that ironical?).

Would you think that it is better if I wrote: Linking surveys? Do not start this, because Limesurvey was never designed for it and it will make your life miserable?

You even hint at saying that what I am doing should be given no chance, because soon we will have a marketing manager that will say that this is impossible, because the main competitor also does not give these possibilities.

And to answer your question about equations: I thought that when a variable is defined in an equation, you might as well transfer it to another equation. Simple as that.

Please do not forget that having superior knowledge of a tool (like you seem to have) does not lessen the need for documentation for people that have less knowledge....

tammo wrote: Thanks for writing a more accessible manual section. (Is that ironical?).

There is no irony in my posting. Irony isn't working online.

If people struggle to get the URL linking working, they won't be exposed to the other problems which are connected to linking surveys.

It is still good, to improve the manual and get URL variable (for panel integration and linking surveys) handling explained well.

Your wrote:

This became very frustrating, since after more than a day of defining questions, I found out that the survey had become too large.

I only can imagine how frustrating it will be when to distribute a complex, big survey over two or more linked surveys and learn the hard way that you cannot easily access the values of questions across the surveys.

And to answer your question about equations: I thought that when a variable is defined in an equation, you might as well transfer it to another equation. Simple as that.

That's why I am asking. It isn't simple as that. To get everything through an URL is not easy. It looks easy on the first sight and with simple examples. But it can get really nasty really fast. If you have a few array questions you need to convert them all into a mass amount of variables. And surveys which hit the database limits seem to have some of these questions as well.

Please do not forget that having superior knowledge of a tool (like you seem to have) does not lessen the need for documentation for people that have less knowledge....

I have no superior knowledge of LS. I have only experienced the situation with linking. Hopefully I learn some new tricks to move answers more easily between linked surveys.

Feel free to ignore my post. I clearly stated that I like the idea of getting URL variable handling documented in a better w
ay. My warning is that you cannot easily split a survey when hitting the database limits. You have to check the amount of data with is needed across the linked surveys.

In a nutshell: If you consider linking surveys to prevent database limits, try to redesign the survey first. to get below the database limit. Linking surveys is a lot more work than it looks on the first look.

That takes nothing away from your effort to improve the manual.

Well, first of all Jelo is a very "critical" user, which is good, but might seem to be very direct sometimes.

I also think, that it is not ideal to have to join survey because they are getting too big. It is always a workaround and workarounds, while nice if you can do something that you could not do out of the box) should be kept to the minimal. I don't know how big the demand of big surveys is among Limesurvey users. And I always recommend to keep surveys short anyway. But you do not need to have extremely long surveys to run into this problem. A few longer multipe-Choice questions or Matrix questions and you are running into these database limits easily. Let's just assume you want to ask someone which countries they have visited before. There are about 195 countries, which will already require at least 195 columns for a multipe answer question. If you then go on a bit and need to use this list of countries again for some other question, you have used up almost 400 columns for 2 questions.

I think for future releases we should at least discuss the concept of longer surveys again. I am not a developer and I can't say much about the database structure being "weird". I am not sure how it could be made better. I am wondering how difficult it could be to create a feature that could just join 2 or more MySQL tables to improve this limit. It wouldn't require a whole ne structure for the database I think.

holch wrote: But you do not need to have extremely long surveys to run into this problem. A few longer multipe-Choice questions or Matrix questions and you are running into these database limits easily. Let's just assume you want to ask someone which countries they have visited before. There are about 195 countries, which will already require at least 195 columns for a multipe answer question. If you then go on a bit and need to use this list of countries again for some other question, you have used up almost 400 columns for 2 questions.

Your 195 country question will be a good example to show the issues of linking answers via Get URL parameters.
How many variables are needed if no answer limit is on that 195country question?
So far I came up with two answers 195 or 1.

195 variables, if every possible answer gets a variable.
1 variable, if you double the answer code for every answer. (e.g. Country A = 1, Country B =2, Country C = 4 ...)
Value 5 = Country A and C were chosen.
If using one variable you will have to add code which converts the number back into answers.

Open answers e.g. Text
If you have Text to pass, you need to ensure, that it gets encoded for being used in the URL and than decoded back afterwards. The URL is not allowing all characters that a respondent can enter.
en.wikipedia.org/wiki/Percent-encoding
LimeSurvey is not doing this automatically. It's need to be done for nearly ever text (at least if respondent can enter it).

I haven't found more quicker or elegant way in the years bridging surveys with Limesurvey and other surveytools.

tammo wrote: You even hint at saying that what I am doing should be given no chance, because soon we will have a marketing manager that will say that this is impossible, because the main competitor also does not give these possibilities.

I was talking about the database limits, not the feature set.
Custom variables are available in many survey packages. The main competitor hat that feature too.
help.surveymonkey.com/articles/en_US/kb/...nd-how-do-I-use-them

The purpose of getting data via URLs in and out of a survey is quite common (CRM, Ads, different invitationlinks, prize registration after a survey).

You shouldn't feel demotivated by my posts. I even provided you some workarounds for linking surveys under LTS. I'm only one user. Nothing more, nothing less. Since I haven't hit the database limits with my surveys let's wait for other users to join this discussion.

holch wrote: I am not a developer and I can't say much about the database structure being "weird". I am not sure how it could be made better. I am wondering how difficult it could be to create a feature that could just join 2 or more MySQL tables to improve this limit. It wouldn't require a whole ne structure for the database I think.

www.limesurvey.org/manual/Database_Stora...t_M1_Database_Design

2 related posts:

www.limesurvey.org/community-services/fo...leased/142509#142010

www.limesurvey.org/forum/spanish-forum/1...ntidad-de-limesurvey

Thank you Ben,

I used the first link in the article, I will try to translate the second, my Spanish is not good enough.

Besides that I have made the warning that this is a workaround only more clear, so people will think twice before starting with linking surveys.

Tammo

Translation of
www.limesurvey.org/forum/spanish-forum/1...ntidad-de-limesurvey

Well this is a possible entity diagram about Limesurvey DB. It should be clear that the greatest utility of this is for "visual guidance" of the db process/scheme and is subject to possible errors or modification due to the fact that the database uses the MYISAN engine and that the use of any software that allows reverse engineering will return only the tables. You will be able to visualize the file with visual paradigm 14.0 and you can also modify it if needed.

I wanted to thank you with the "Thank you" button, but I got an error that I have been banned. Strange.

sure you will be de-banned ASAP and your highly respected LS status restablished