Database/Drivers/MySQL Native/Known Driver Problems

From Apache OpenOffice Wiki
< Database‎ | Drivers‎ | MySQL Native
Revision as of 19:01, 7 January 2009 by Nixnutz (Talk | contribs)

Jump to: navigation, search

Connector/OpenOffice.org development issues to discuss with OOo team

Base related

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.

OOo shows unrelated databases/schemata

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.

Unclassified: Base and/or Driver related

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.

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.

MySQL related

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() COLUMN_SIZE

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize(). getDisplaySize() returns always 20, which needs to be tweaked on a per-datatype basis.

Affected: DECIMAL/FLOAT.

DatabseMetaData::getColumns() DECIMAL_DIGITS

DatabseMetaData::getColumns() does not set DECIMAL_DIGITS. Therefore, Base does not show it properly.

Unclassified and first preview version related issues

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 issues

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.

Personal tools