Hey there, is it possible to test again the upgrade process and see which issues are popping up? Fixes were pushed in LS 4.4.x

Sure. Tested again today, from 3.25.x to 4.4.4.

I can confirm the special char encoding bug is gone!

However, I still get

CDbCommand konnte das SQL-Statement nicht ausführen: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'code' at row 291. The SQL statement executed was: INSERT INTO labels
(lid, code, sortorder, assessment_value)
SELECT lid, code, min(sortorder), min(assessment_value)
FROM labels_update400
GROUP BY lid, code

The respective table content looks like this:

MariaDB [eval]> SELECT lid, code, min(sortorder), min(assessment_value) FROM labels_update400 GROUP BY lid, code limit 25;
+-----+-----------------+----------------+-----------------------+
| lid | code | min(sortorder) | min(assessment_value) |
+-----+-----------------+----------------+-----------------------+
| 1 | engagiert | 2 | 0 |
| 1 | erklaertgut | 1 | 0 |
| 1 | gehtaufBeduerfn | 3 | 0 |
| 1 | vorbereitet | 0 | 0 |
| 2 | A1 | 0 | 0 |
| 2 | A10 | 9 | 0 |
| 2 | A2 | 1 | 0 |
| 2 | A3 | 2 | 0 |
| 2 | A4 | 3 | 0 |
| 2 | A5 | 4 | 0 |
| 2 | A6 | 5 | 0 |
| 2 | A7 | 6 | 0 |
| 2 | A8 | 7 | 0 |
| 2 | A9 | 8 | 0 |
| 3 | A1 | 0 | 0 |
| 3 | A2 | 1 | 0 |
| 3 | A3 | 2 | 0 |
| 3 | A4 | 3 | 0 |
| 3 | A5 | 4 | 0 |
| 4 | SQ001 | 0 | 0 |
| 4 | SQ002 | 1 | 0 |
| 4 | SQ003 | 2 | 0 |
| 4 | SQ004 | 3 | 0 |
| 5 | SQ001 | 0 | 0 |
| 5 | SQ002 | 4 | 0 |
+-----+-----------------+----------------+-----------------------+

Thx - will get it in our backlog :)

I cannot reproduce the issue. THe label code should never be longer than 5 chars and this limitation has been in the database forever.
Most likely you have modified the table to allow for longer codes - might that be?

This is a vanilla install dating back to 2016 approx., no plugins whatsoever.
Setup on 2.x if I remember correctly.

No, the DB has never been touched, this must have been possible via the standard web GUI.

I can adapt this for this installation, I guess (hope it does not need changes in other locations?).

Still - this might not be the only installation where this happened and the fix should be in the upgrade process, i.e. shorten to 5 chars, see whether the label is still unique.

Column "code" is defined as varchar(15), so the application should support that. If this is not intended, it should be reduced to varchar(5) so we do not end up with unexpectedly long data in the DB. Better throw an error right when the application tries to write beyond bounds not expected than write unsupported data to the DB!

I checked back our source code to the beginning of LimeSurvey. The code never had a length of 15, it has been always 5 since LimeSurvey was created. This must have been manually modified.
I will close this issue now.

As a note to myself and anyone running into the same issue:
There do not seem to be any more references to these codes in the DB, so they can be shortened.

https://github.com/LimeSurvey/LimeSurvey/blob/25f63d5758134ad5eca607453deb8a9e94b7f2bd/installer/create-database.php#L177 creates the column with string(20) now, but this happened only in DB version 483.
If longer codes are needed, they can be restored on LS5.x or LS6.x.
(Though I still don't know why mine where longer.. Don't need this, actually)