6.4.1 -> 6.4.2 migration issue ?

Hello,

today we changed our application server from a virtual machine to a real server (and the database is on its own server).
So we set up the new server and copied the whole /var/www/projeqtor/ directory to the new server (and we didn't change anything on the database server).
At the same time, our IT decided to also upgrade to 6.4.2

Issue #1 :
The software is working correctly except we now have UTF8 issues as "enregistré" instead of "enregistré". What's worrying me is that the data itself looks incorrect in the database (obviously, everything was correct until then).

When I look to the log file I can see following lines :
***** ERROR ***** [V6.4.1] mbstring module not enabled (mb_check_encoding not existing) : install module and unable module in php.ini
***** ERROR ***** [V6.4.1] Impossible to load class ZipArchive<br/> => Not found in ../model/custom/ZipArchive.php <br/> => Not found in ../model/ZipArchive.php <br/> => Not found in ../model/persistence/ZipArchive.php <br/>
***** ERROR ***** [V6.4.1] Impossible to load class DOMDocument<br/> => Not found in ../model/custom/DOMDocument.php <br/> => Not found in ../model/DOMDocument.php <br/> => Not found in ../model/persistence/DOMDocument.php <br/>

Issue #2 :
I can't say I saw it, but I guess those lines in the log file look quite incorrect :
***** ERROR ***** [V6.4.2] Exception-[42S22] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'work.rate' in 'field list'
***** ERROR ***** [V6.4.2] For query : select work.id as id, T1.fullName as nameResource, work.idResource as idResource, T2.name as nameProject, work.rate as rate, work.idle as idle,work.idProject as idproject from work left join resource as T1 on work.idResource = T1.id left join project as T2 on work.idProject = T2.id where 1=1 and idResource in (4, 6, 25, 13, 10, 9, 14, 18, 8, 15, 31, 12, 32, 5, 27, 7) order by work.id desc
***** ERROR ***** [V6.4.2] Strack trace :
***** ERROR ***** [V6.4.2] #0 Sql->query called at [/var/www/projeqtor/tool/jsonQuery.php:701]


[EDIT]
I'm afraid I have a part of the answer: my IT installed PHP 7 on the new server ...

OK for prerequisites, my IT installed it just after the messages.

the UTF8 line in parameters.php doesn't seem to change anything (at least now, maybe it could have changed something during the migration process).
It seems that only the short name fields suffered of this UTF8 issue: indeed, the descriptions, results and so on (rich text fields) does not have any problem. I can't verify the db right now, but I guess they have the same type.

Well, I manually corrected the important lines. It's not such a big issue in my case.

Hello,

the database shows the exact same thing as I can see in the gui :
- If the displayed field is incorrect : the data in the db is incorrect
- If the displayed field is correct (I manually corrected it) : the data in the db is correct

such fields in the db are now defined as follow (eg for the name field of actions):
name varchar(100) utf8_general_ci

hope this helps.

I corrected almost every weird characters in my database, so I guess I shouldn't face this issue anymore.