Database/Drivers/MySQL Native/Known Driver Problems
- 1 Connector/OpenOffice.org development issues to discuss with OOo team
- 1.1 Base related
- 1.2 Unclassified: Base and/or Driver related
- 1.3 MySQL related
- 1.4 Unclassified and first preview version related issues
- 1.4.1 Subforms do not work
- 1.4.2 Tools -> User Administration... User administration is offered in the UI, but yields an error when chosen
- 1.4.3 Tools -> Relations... not working
- 1.4.4 FIXED issues
Connector/OpenOffice.org development issues to discuss with OOo team
Empty schemata not shown
Create an empty schemata/database. Create a new Base database which connects to an empty MySQL database. The MySQL database is not show. Reason: OOo calls getTables() - no tables - schema not displayed. Setting might even be cached - verify that database becomes visible after creating table (from mysql prompt) in schema.
DECIMAL shown as TEXT
Base shows numerical DECIMAL columns as TEXT. I'm 95% sure C/C++ and C/OOo report a proper column type.
Create a new Base database that connects to a MySQL schemata "test". Have "test" in the connection settings! OOo will ignore it and query MySQL for all tables in all schematas.
000514/01/0000116 OConnection::getMetaData 0000515/01/0000117 ODatabaseMetaData::getURL 0000517/01/0000118 OConnection::getMetaData 0000518/01/0000119 ODatabaseMetaData::getTables 0000519/01/0000120 >MySQL_ConnectionMetaData::getTables 0000520/02/0000121 | INF: catalog= schemaPattern=% tablePattern=%
As a consequence the user will see all schemata he has access to not only the schemata/database "test" as requested in the connection settings
No default schema on table creation
Base does not preselect a default schema in the table editor dialog. Its does not even if you connect to a schema (see also OOo shows unrelated databases/schemata)
No way to set MySQL specific table attributes
The Base table editor does not give access to table attributes. Not even basic ones such as the Engine (MyISAM: non-transactional, InnoDB: transactional).
Base does not recognize schema changes
After connecting to a database and opening a table once, Base will not recognize changes applied to the DB schema meanwhile when opening the table in the table editor again.
Base table column comments
Likely a Feature Request: Base table column comments are not synchronized with the MySQL DB and its schema.
Violation of FK constraint give two errors instead of one
Create two tables. Have one table "derived" reference entries in the other table "source". Try to remove a referenced record from the table "source". MySQL will report an error stating that you are violating a FK constrain. When using the MySQL JDBC driver the Base shows one requester with stating something like "Error - (error message from MySQL)". When using the native driver you get an requester stating "error" and you can proceed to an error details dialog. In the details dialog you will find two errors. The first has no message, the second shows the error message provided by MySQL.
-- Dump completed on 2009-01-08 2:06:16
Default values not properly processed
The Base table editor neither properly sets default values nor does it re-engineer default values properly.
SMALLINT becomes REAL
When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base
BIGINT values crippled?
Large BIGINT values are displayed in Base using scientific notation: 1e+15. If one changes the display format to number #.### the first 14 values of a large number (9223372036854775807) are displayed properly but then some rounding takes place, for example: 9223372036854800000. Connector/C++ can handle long long (L64) values properly and Base does use getLong() nevertheless the displayed value seems wrong.
TIME value range
TIME data type may have a significantly larger value range than the Base counterpart.
INSERT does not work
Inserting data into a simple table does not work. Works fine when using the JDBC driver.
CREATE TABLE `source` ( `id` int(11) NOT NULL, `col1` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `idx_col1` (`col1`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
information_schema (I_S) not shown in schema list
SHOW DATABASES shows the I_S. When quering the I_S for schema, the I_S will not expose itself. Different versions of Connector/C++ use different ways to fetch schema lists. Until and including Alpha SHOW DATABSES is used.
When using the JDBC driver and specifying no database in the connection URL no schemata are shown at all.
TINYINT / BOOLEAN
Educate Base users on MySQL Server type mappings, for example BOOL[EAN] -> TINYINT.
DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize(). getDisplaySize() returns always 20, which needs to be tweaked on a per-datatype basis.
DatabseMetaData::getColumns() does not set DECIMAL_DIGITS. Therefore, Base does not show it properly.
Subforms do not work
Well, some of them do ... more precisely, SQL statements with named parameters (":param_name") do not work in general. The ODBC/JDBC driver wrapper used to replace them with unnamed parameters ("?"), since MySQL does not understand them, but the native driver does not do this, yet. Since subforms usually make heavy use of such named parameters, they currently fail.
Tools -> User Administration... User administration is offered in the UI, but yields an error when chosen
Same restriction applies for MySQL JDBC driver -> won't fix?
Tools -> Relations... not working
Error message: Database not support relations. Same restriction applied to JDBC driver -> won't fix?
FIXED: Existing table fields cannot be altered
The implementation simply didn't get that far (css.sdbcx.XAlterTable not implemented) ... for the final release, we expect this to be fixed.
FIXED: The user interface is not remotely intuitive
That's true. The final version will run in OpenOffice.org 3.0 only, which will have a dedicated and thus vastly improved UI. FIXED: The driver doesn't run in OpenOffice.org 3.0 developer snapshots
Well, it's not intended to do. Please use it with the 2.4 release only, everything else is not supported right now, and may lead to all kinds of unwanted results.
FIXED: Specifying a different socket path is not supported (Linux)
Currently, the driver expects the socket to be /tmp/mysql.sock. This is hard-coded, and will be fixed with new UI (3.0). There are 2 workarounds:
1) Specify an IP number and a port number, like this: 127.0.0.1:3306/yourdb. In this case the driver will establish a connection via TCP and not a local socket.
2) Add a link from the real socket file to /tmp/mysql.sock by running this command "ln -s /<path to file>/mysql.sock /tmp/mysql.sock". However, this will probably need to be done by the root user and depending on your computer's settings the /tmp folder may be cleared each time the machine restarts. Meaning that this must be done after each boot.