I believe the problem is here:
https://github.com/LimeSurvey/LimeSurvey/blob/master/application/models/SurveyDynamic.php#L127

The error should be handled outside the model as to be able to know what happened.
Options:

• Log the error inside the model (don't like it)
• Store the error on the model (new attribute -- I don't like it)
• Move the exception handling outside of the function (https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/expressions/em_manager_helper.php#L5058). That way we will be able to send the exception message on the SQL parameter query (or in the message it self.)

@DenisChenu thoughts?

@tbart do we have reproduction steps?

Another option would be to setup a new file logger on the internals and start logging these kind of things.

I always think we must remove insertRecords and use cleand response model

We do it for update : https://github.com/LimeSurvey/LimeSurvey/blob/e4ce8389830892d6e1cd06eafec624d978d7b910/application/helpers/expressions/em_manager_helper.php#L5147
3.X : https://github.com/LimeSurvey/LimeSurvey/blob/5354af48a108cd0b20aee406641520c22204bcec/application/helpers/expressions/em_manager_helper.php#L5597

Added to use PDO : https://github.com/LimeSurvey/LimeSurvey/pull/1353

Else

I believe the problem is here:

There are 2 issue here

1. $record->encryptSave(); didn't validate : we must validate : it fill the https://www.yiiframework.com/doc/api/1.1/CModel#getErrors-detail
2. Maybe we can send the $e to https://www.yiiframework.com/doc/api/1.1/CModel#addErrors-detail ? in some way ?

One idea :

insertRecords do

1. validate : if not return false ($model->errors ar filled)
2. try/catch saveEncrypt : $model->addError('id', $e->message) : put it in id (why not)

But i think best solution is to use model directly and remove usage of insertRecords (maybe just the minimal : insert empty recorrd).

PS : here : https://github.com/LimeSurvey/LimeSurvey/blob/master/application/helpers/expressions/em_manager_helper.php#L5167C37-L5167C37

It must not be

submitfailed(CHTml::errorSummary($oResponse)) ?

Else i found this to have the SQL : https://stackoverflow.com/a/60170086

I always think we must remove insertRecords and use cleand response model

That looks more like a change for DEV.
Too risky for a bug fix from my POV.

insertRecords do
validate : if not return false ($model->errors ar filled)

We can set the parameter of saveEncrypt to true, and will do the trick.
I think it is worth it.

try/catch saveEncrypt : $model->addError('id', $e->message) : put it in id (why not)

I don't like to try/catch inside the model.
It could be fine, but

• we don't do it anywhere else.
• The real handling would be delegated to be done outside, not by the try catch but by the error model, so why catching it?
• A model error is one thing (rules broken) and an exception is another, don't like to mix this concepts.

I would just not handle it inside the model, and handle it outside.

Another option would be to setup a new file logger on the internals and start logging these kind of things.

You don't like the idea of only logging SQL queries which failed? Also errors?
Somehow I believe this logging option is not out of the box.

You don't like the idea of only logging SQL queries which failed? Also errors?
Somehow I believe this logging option is not out of the box.

Why an new logger ?

Just use Yii::log ad error if you want

But : need to send the error in email.

Else

That looks more like a change for DEV.

Maybe but i think it's the only good way to fix … or just add $e->message to the email and «basta»

Why an new logger ?
But : need to send the error in email.

People need to see the error. If it is SQL, good. But I guess error log will be better than nothgin (and easier). Probably will be enough.

Just use Yii::log ad error if you want

Problem is that by default, on live envs, nothing is logged, not even errors.
Usually even hard to find PHP errors on webserver logs (sometimes I find them, sometimes don't).
So enabling a way for error loggin on file out of the box could be a solution for this and other unkown (hard to reproduce) situations.

That looks more like a change for DEV.
Maybe but i think it's the only good way to fix … or just add $e->message to the email and «basta»

For me, 2 different tickets: BUg and Enahncement.

then adding $e->message in email.

then adding $e->message in email.

Yes, consdering then that the exception is not treated inside the model

I'd very much like to add reproduction steps, but that's a chicken and egg problem. If I don't know when something goes wrong, I am unable to trigger it :-(
If there's an easy interim patch I can add to the mailing function, I can do so and we'll probably see a little more if we hit the error by chance. It might reveal details for better reproduction as well!

Will prepare something so you can apply individually and test... You were referring to that?

Master: https://github.com/LimeSurvey/LimeSurvey/pull/3372

@tbart : a way to test

Activate a survey (number 1234)
Lauch,
Move to 1st page

Rename a column of survey_1234 via the DB

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

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

Tested and merged fix for master.