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