Description: All I mentioned on this discusion with printshots: https://ask.libreoffice.org/t/connection-to-mariadb-via-connector-c-not-working/97171 I am there as PetrEU Steps to Reproduce: 1.Follow the link please 2.https://ask.libreoffice.org/t/connection-to-mariadb-via-connector-c-not-working/97171 3. Actual Results: Run and configure MariaDB on Windows 2012, Install Connector C, Make Libre office Base form try to write and READ data. Expected Results: It is possible to write everething to MariaDB but not to read it correctly back just in SQL query is reading possible. Again in the form even through querry is not possible to read. Reproducible: Always User Profile Reset: Yes Additional Info: https://ask.libreoffice.org/t/connection-to-mariadb-via-connector-c-not-working/97171
Repro using Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded and also using current master; both on Windows 10 Home. A. Install and run MariaDB Server 1. Download a release of MariaDB Server (Windows x86_64) ZIP file from https://mariadb.org/mariadb/all-releases/. Either 11.1.2, or 11.0.3 would do. 2. Unpack the ZIP file into a directory. 3. Start cmd.exe. 4. Execute '<unpack_directory>\bin\mariadb-install-db.exe'; wait for its completion. 5. Execute '<unpack_directory>\bin\mysqld.exe --console'; let it run. B. Create a database and a table 6. Start another cmd.exe. 7. Execute '<unpack_directory>\bin\mysql.exe -h localhost -u root', to start MariaDB shell 8. Execute 'create database tdf_bug;' 9. Execute 'use tdf_bug;' 10. Execute 'create table bug_table (val int);' 11. Execute 'insert into bug_table values (0), (1), (2), (3);' C. Reproduce the bug 12. Create a new Base Database. 13. Select 'Connect to an existing database' -> 'MySQL/MariaDB'; click [Next]. 14. 'Connect directly (using MariaDB C connector)'; click [Next]. 15. Database name: 'tdf_bug'; Server: 'localhost'; port: unchanged (3306); click [Next]. 16. User name: 'root'; keep 'Password required' unchecked; test connection; click [Next]. 17. It is not required to register it to see the bug; Open the database for editing; click [Finish]. 18. Save the ODB file. 19. In the Tables view, collapse the 'sys' list, and expand the 'tdf_bug' list. 20. Double-click 'bug_table'. => The opened table shows the four rows, but all values in the val column are 0. D. Check that the correct data is returned by executing SQL directly. 21. Close the table. 22. Tools->SQL; Command to execute: 'select * from bug_table'; check 'Show output of "select" statements'; press 'Execute'. => Status: '1: Command successfully executed.'; Output: 0, 1, 2, 3, It doesn't matter if you create a primary key or not (the steps avoid that, to have the simplest table possible).
Seems you could start a query with Tools → SQL to the MariaDB and it gives the right content. If opening the table directly it will only show '0' instead of other Integer values, only show a default date like 1900-01-01 instead of the date, which could be seen in Tools → SQL. Varchar fields will also show unknown signs and not the right text content. This buggy behavior has nothing to do with character set, because there is also DATE and INTEGER affected. I couldn't confirm this behavior under OpenSUSE 15.4 and LO 7.6.2.1, but see the screenshots on https://ask.libreoffice.org/t/connection-to-mariadb-via-connector-c-not-working/97171 MariaDB, direct Connection, Windows-Server: Data could be read by Base through Tools → SQL, but not by the GUI (table, form …)
Also repro using Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL But worked fine using Version: Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Regression after commits fe041bbc343ee08c6e901f63985d55a90da71c8b (mariadb: upgrade to release 3.1.8, 2020-06-16) and 82a1650683df7d5c1769dfd68a26a4d071f1a546 (mariadb: the "pvio_socket" plugin turns out to be important, 2020-06-17). Before the former, it worked OK. between them, it showed "Plugin pvio_socket could not be loaded: The specified module could not be found. Library path is '/usr/local/lib/mariadb/plugin/pvio_socket.dll'" error. After the latter, it shows wrong data.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5a0498ded11d514c21e3124333a3560da1373202 mariadb connector: upgrade to release 3.3.7 (fixes tdf#157826) It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/77a8401c41040e5a36f2bd980ec66ecdad0562d8 mariadb connector: upgrade to release 3.3.7 (fixes tdf#157826) It will be available in 7.6.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tested a modified version of the last daily builds. The data transfer is now correct. Everything is running briskly and I haven't encountered any problems so far. Only comment: all unfilled dates in my form are implicitly filled with the minimum date range i.e. 1.1.1900. When transferring via ODBC, the date fields remain blank when transferring to the form from the same database. Would it still be possible to modify this? I.e. not to fill in for the date, empty fields or null fields, to the minimum value, but leave them really empty. Thank you.
(In reply to Petr Poruban from comment #7) > all unfilled dates in my form are implicitly filled with the minimum date > range i.e. 1.1.1900. Please create a separate bug report for that. It is a different issue, that needs to be tracked separately.