Due to new "Question code naming".

See: https://github.com/LimeSurvey/LimeSurvey/commit/4ded98eec374d39e7668a943d18db34118cbd795

That is a regression. Variable names should be allowed to contain underscores too. They should also be allowed to start with an underscore. Otherwise there is no reliable way to upgrade old surveys that use that valid 1.92+ naming convention.

http://www.limesurvey.org/irclogs/limesurvey-team/index.php?date=2013-12-03

PS: underscore are valid too in 2.0, not only in 1.92 ;)
PS2:
https://github.com/LimeSurvey/LimeSurvey/commit/4ded98eec374d39e7668a943d18db34118cbd795#commitcomment-4741089

We definitely need to fix this and make it "somehow" backward compatible. I think this was discussed in length at the previous dev meetings. I just don't want users to update and find liots of their surveys broken

I read the team logs, and it isn't clear why underscores would be problematic for 2.05. I doubt that people would mix auto-generated and manually-generated variable names. If so, there is minimal risk of naming conflicts. Besides which, the Show Logic File functionality detects and highlights re-use of variable names, so if someone accidentally re-used a variable name, they could easily spot and fix the problem.

By contrast, some people, like me, routinely use underscores in variable names. So, disallowing underscores would break 90%+ of my surveys, and there is no easy or reliable way to convert those variable names to something else.

I second this. About 80% of our users are using underscores so even though we have discussed that in length, maybe we can find a way to support underscores.

2 change between 2.00 good code (don't show alert in EM files)

• Underscore in Question code and/or SubQuestion code
• SubQUestion code starting by a numeric value : this one is due to Ranking question type.

Deleted relation ship : #08514 are for 2.00 too : we test SubQuestion code case-insensitive in javascript only.

It sounds as though there may have been several major changes from 2.0 to 2.05, including:
(1) Disallowing underscores in variable names
(2) Disallowing use of purely numeric sub-question codes
(3) Case-insensitive sub-question code tests in JavaScript (Denis's note above)

All of these are actually major behavior changes for my surveys, and likely for many other users. I am still not clear on why these changes were thought to be needed -- I expect there must be a way to support backwards compatibility.

Regardless, I think this topic needs to be discussed/debated in the public forum, not just the developers and bug lists, since this will have a major impact on users.

Hi Thom :
2: are removed in last update: only numeric in sub question code is allowed now
3: It's clearly a bug here , with sub question code Q1 and q1 give the same "column name" for mySQL. Maybe it's OK in msSQL and pgSQL, but most of our user use mySQL actually.

You really use same question code : example a1 and A1 (for same question) ? Never have problem ?

Carsten-

Glad you are working on this one, although I expect there are higher priorities. Please clarify why 2.05 and beyond would not be able to cope with underscores.

Expression Manger gracefully handles variable names that follow this pattern, so I'd expect 2.05 to be able to do the same:

/^[a-zA-Z][a-zA-Z0-9]*$/

hi Thomas,
the long-term plan is to move away from the old SGQA naming (for example the field names in the response table) to unique question codes where the underscore will be reserved as separator character - that's why underscores will be obsolete in the future.

I am just converting the example surveys one by one trying to find a way to cleanly rename the variables inside the expression.

For condition based stuff it is easy to just recalculate the expression, for custom expressions you would not know an easy way to find and replace an old variable name for a new one? I guess a regex should be able to cover that.

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=13853

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=13862

2.05+ Build 140212 released

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=14015