When opening a table for viewing (similar when opening a form or query on this table) the following error is shown: "Unknown column type when fetching result" The problem seems to be a column of the type year(4) MariaDB [projekte]> show columns from rueckfluesse; +------------------------+----------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------------------+----------------------+------+-----+---------+----------------+ | Buchungsjahr | year(4) | YES | | 0000 | | (LO shows the column definition as TEXT[VARCHAR]) This problem does not occur with LO 6.0.7.3 (same base file and same database).
@hojp : please specify : - which driver you are using (native connector, ODBC, JDBC) and version) ; - which OS and which provider of the LO packages you are using if on Linux ; - does it change anything in the behaviour if you remove the default value defined in your table ? There have been previous similar reports with datetime fields. Setting NEEDINFO
Oh sorry, should've read the title, you mention the native connector, so JDBC and ODBC are excluded. Still, could you please provide us with the OS and package versions if you are using Linux ? For comparison, does the problem also occur with a mysql database instead of a mariadb database ?
I am using debian testing. libreoffice-base 1:6.4.3-1 libreoffice-mysql-connector 1:6.4.3-1 I have not tested this setting with mysql server nor will this be easily possible. In earlier years this worked with mysql server. However, there is also no bug with mariadb and LO 6.0.7.3 (same base file and same database) on ubuntu 18.04. The bug also does not show in the debian 6.4.3-1 setting, if I connect to the database via mariadb ODBC driver. Therefore, I guess that the bug is connected to the ibreoffice-mysql-connector in its newer version.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to hojp from comment #0) > This problem does not occur with LO 6.0.7.3 (same base file and same > database). Before LO 6.2 there hasn't been a native connector integrated in LO. So could be you used the special connector of your system. There have been extensions for this connector, but they weren't available for every system. I could connect to a table with the Column Type 'year' in LO up to LO 6.3 - but I can#t insert any values on a table up to this version and the content isn't shown right. Since LO 6.3 I get the error-message you also get, because the native connector doesn't know anything about the column type 'year'. If you try it with JDBC it will show 'date' for this column and couldn't enter data. And with ODBC it will show 'smallint' for this column - the only working connection for this field type. I will set this bug to new, switch the version to LO 6.3 and set it as a ask for an enhancement, because there is no datatype available with any connection to MariaDB/MySQL for the special tape 'year'. Tested all with different LO-Versions. First Version with this error was LO 6.3, but before this version it was impossible to add data to a table with the native connector here. Tested with OpenSUSE 15.1 64bit rpm Linux.
We switched from ODBC to a native LO Base - Mysql connection sometime in 2012 and have been using this including the year column ever since without problems. To my recollection ubuntu always had the libreoffice-mysql-connector (maybe under a different name in earlier version) in its main repositories. 18.04 currently uses "1.0.2+LibO6.0.7-0". We never used a connector separately installed as an extension. Addressing and editing the year(4) column with LO 6.0.7 and earlier natively has never been a problem since 2012. The newer version of Base or the connector seem to be the problem. The same error also occurs under Manjaro 20 with LO 6.3.5-4 or LO-fresh 6.4.3-1.
Fixed with: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2d445f90dbecf8d2240474dcb06084868ceb921a tdf#145714: teach "mediumblob" to Mysql/MariaDB part in LO also teach about: TINYBLOB + LONGBLOB + TINYTEXT + MEDIUMTEXT + YEAR + BIT (You'll have to wait for LO 7.3.0)