You may find a new entry in the forum directly releated with this 5y old feature request:

https://www.limesurvey.org/forum/can-i-do-this-with-limesurvey/111832-i-need-to-increase-the-answer-code-length/155977

An increase of answer code length up to 12 alphanumeric chars will considerably provide a gain in interoperability and be welcome by new or recurrent users working in scientific fields and looking for a survey or data entry tool.
For example this will be enough to accept worldwild used SNOMED-CT and standardized Health Care Provider Taxonomy codes (no dot or hyphen chars) .

The new LS.3 beta release may be a good moment to introduce this update.

Remind : if we put a big number : the we lower the number of allowed columns :/

Where? Why?

https://manual.limesurvey.org/General_FAQ#...regarding_survey_size

ok... but for very extreme cases (imho).
I think the best would be a choice during the install standard/personalized (as many other softwares do) offering the possibility to adapt this setting and some other ones.... and more likely for LS4 !

I vote for adding the feature of longer question and answer code fields at Limesurvey 4.0.
At Limesurvey 3.x the field size for question and subquestion codes is 20 and for answers it is still just 5. That's not much, it would be great if we could improve this.

@c_schmitz, what is your opinion n this? What are the pros and cons?

If we still use mysql/ISAM : this allow less single choice question …

answers.code is still varchar(5)

I am assigning this to Carsten so he can decide if this improvement is doable with a reasonable effort because it would be very helpful to lots of users.

@c_schmitz, any chance to improve/extend the answer code length at LS 4?

It is not planned for LS4 - probably LS5.

@c_schmitz, the question is why it is not simply possible to ALTER TABLE `answers` CHANGE `code` `code` VARCHAR(25) NOT NULL

If we still use mysql/ISAM : this allow less single choice question …

You really want to allow less question ? Really ?
Original issue ask for 128 , but why not 512 or 1024 ? No limit‘s …

The only solution is QuestionObject with "column type"

@DeniChenu: Good point. So why not having a global setting for this + maybe a local survey setting "Answer code length"? Then the user is free to adjust this as needed and we only need to apply the proper setting at survey activation.

Besides the DB limits/size, are there any further potential side-effects you can think of?

A question : what is the purpose ?

When you need this code ?

Because if it's

• Survey ( {QUESTION_CODE}) : it can be already done
• Export : it can be already done
• ? …

Else if it's in config.php : what happen for answer table when it's updated … need to update too …

Regarding the use case: At complex surveys if you want to use more speaking codes an answer code like "male" works fine but already "female" won't work. Some companies have predefined codebooks for their surveys and these often use longer answer codes.

OK, but WHEN this is needed ?
As export : easy : create a plugin table with qid/code/newcode and use it when export.

PS : i have such issue with code like BE_VSL : i do a recode (becaus it's only one comulon) : it's not really an issue

Those codes are required at data export mostly.

Then at data export : my opinion is

1. Create a plugin table qid,code,exportcode
2. When exporting : get this code from plugin table

:)

You can do it too in question adv setting with a textera like this

M:Male
F:Female

Else : a 4.0 solution

1. Set answer code to 25 in answer table
2. Same for labels
3. Add an advanced setting 'code column width' : read only when active, default to 5
4. Min/max from 1 to 25

Create column when activate

What can broke

1. Import oid survey table
2. Import VV
3. Import LSA

This need time … and currently 4.0 have a lot of another issue

I like the 4.0 solution.

@c_schmitz, any chance to add that at LS 4 if we take care of the coding?

No chance for this in 4.x - sorry.

@DenisChenu, would a plugin be able to:

a) Extend the minimum character length for the code field when adding answer options? Maybe this could alternatively be done by some JS within a custom admin theme?

b) Alter the existing DB table: ALTER TABLE answers CHANGE code code VARCHAR(25) NOT NULL?

c) Adjust the code for survey activation so the related fields also provide 25 VARCHARS (simply do ALTER TABLE after activation?)?

By plugin ?????

It can be risky, not before have an event in https://github.com/LimeSurvey/LimeSurvey/blob/77a079d9083ae735dcc3c479194104c4317e84a7/application/helpers/common_helper.php#L1411

This surely add more complexity and issue …

@c_schmitz : why not in 4.0 ? This can be easily added in createFieldMap as a new question adavanced setting without big issue … we wait for have a working develop since month now (when other developer can really test new feature) , but you still disable new feature ???

@DenisChenu, does the createfieldmap() function rely on certain code lengths? Can there be any side-effect with longer answer codes?

@c_schmitz: One of our main customers urgently needs such a feature for route and location details within their transit surveys. No one will be hurt if we add a setting to increase this at LS 4.x and set the default to the know 5 characters, but several users (and Limesurvey as well) will benefit from more flexibility.
We would also provide the required code so you wouldn't need to spend any developer hours on this but just review and comment.

Because activateSurvey use createFieldMap : https://github.com/LimeSurvey/LimeSurvey/blob/ff061148dcc44d9e07000276c046e82bbed737af/application/helpers/admin/activate_helper.php#L290

VARCHAR(128) will probably (?) reduce the amount of maximum columns. See https://stackoverflow.com/questions/2023481/mysql-large-varchar-vs-text/2023513#2023513 and comments.

My proposed solution: Make ALL answer columns configurable in config.php. Right now they are all hard-coded here: https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/admin/activate_helper.php#L295

@ollehar : need update answer table.

Seems to be easiest solution, but : 100 VARCHAR(1) + 1 VARCHAR(25) take less place than 101 VARCHAR(5)

By question : you can have some VARCHAR(1), some VARCHAR(10), etc …

need update answer table

What do you mean?

What do you mean?

If you set single choice column to 20 characters : answer column code mus contains same code.
Here the FR is to allow more than 5 characters to answer code …

Oh, sorry, I misunderstood. But why then not simply run

ALTER TABLE lime_answers MODIFY COLUMN code ...

after installation, if you need longer values?

...because you also need to adjust the GUI to allow >5 characters. You can adjust the source code but if you want to be able to update your Limesurvey system later that is no good approach. So using the configuration setting Denis had mentioned before seems like the best approach to me.

Do we have a PR for this?

@PR: Nope, since we are still discussing if this can be added to LS 4.
If Carsten agrees to it, we could start working on it.

Other alternative: Let the UI limitations reflect the database length of the column. Then the ALTER TABLE command will work.

UI limitations reflect the database length

You mean answer DB length ? Because survey is not always activated :)

You mean answer DB length ? Because survey is not always activated :)

Yes, I mean column code from lime_answers.

Yes, a quick fix can be replace 5 by size of code in lime_answers (get config by database)
But then we always reduce the maximum column numbers :).

It work but not for all survey‘s

No, we don't change the size of code in the database - that's up the each owner to hack/patch. We just lets the UI reads that size instead of hard-coding it to 5.

Maybe we should have a "patch system", which lets you change core code even after an update...

Yes, i understand this :

App()->setConfig('answercodelenght',$databaselength); 
And replace all 5 by App()->getConfig('answercodelenght');

And then : plugin can update confif by a lesser length \o/ for a survey (some hack , but possible)

Yes, exactly. Hacky but better than nothing, I guess.

Why not, a quick solution before allowing a better one .

And since this quick solution us a fixed string : when update to a better one : we can more easily find wher it must be update with a simple grep :)

@Mazi a pull request to consider? Regarding removing the hard-coded UI limit.

@ollehar, please talk about this with @c_schmitz. If he agrees to that approach, we can look into the code details.

He does not. This issue can be put on hold for now.