Bug with tango-db (9.3.4) and mariadb-server (10.11.3) on Debian 12

Hello dear all,

I tried to install a tango server on debian 12.
I used the packages from official debian repositories (mariadb-server, tango-db...).
I used a python script (ConfigureNewDevice.py) to set device properties with a configuration file.
For the first property ("LimaCameraType" = "Simulator"): it's ok.
And for the second, an error occured :

#### Property : "LimaCameraType" = "Simulator"       ( ###  Output from my script ### )
#### Property : "TangoEvent" = "True"                ( ###  Output from my script ### )
Traceback (most recent call last):
  File "/tmp/tmp.j08MRPXx4W/ConfigureNewDevice.py", line 77, in <module>
    tangodb.put_device_property(deviceName, properties)
  File "/home/lima/miniconda3/lib/python3.9/site-packages/tango/db.py", line 536, in __Database__put_device_property
    return __Database__generic_put_property(
  File "/home/lima/miniconda3/lib/python3.9/site-packages/tango/db.py", line 251, in __Database__generic_put_property
    return f(obj_name, value)
PyTango.DevFailed: DevFailed[
DevError[
    desc = Failed to query TANGO database (error=Field 'date' doesn't have a default value)
           .The query was: INSERT INTO property_device_hist SET device='lima/simulator/0000-ccd',id='1',name='LimaCameraType',count='1',value='Simulator'
  origin = DataBase::db_put_device_property
  reason = DB_SQLError
severity = ERR]

DevError[
    desc = Failed to execute command_inout on device sys/database/2, command DbPutDeviceProperty
  origin = virtual CORBA::Any_var Tango::Connection::command_inout(const std::string&, const CORBA::Any&) at (/home/conda/feedstock_root/build_artifacts/cpptango_1683285813364/work/cppapi/client/devapi_base.cpp:1534)
  reason = API_CommandFailed
severity = ERR]
]

I found something on a forum (sorry, I lost the link) : the mariadb configuration STRICT_TRANS_TABLES of the sql_mode variable is apparently a problem.

And I found a solution : insert the line sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION in the [mysqld] section of this file : /etc/mysql/mariadb.conf.d/50-server.cnf. I don't know if this fix will cause any further issues but so far so good.

Best regards, Olivier Neveu