Difference between revisions of "Database/Drivers/MySQL Native/Known Driver Problems"

From Apache OpenOffice Wiki
< Database‎ | Drivers‎ | MySQL NativeRedirect page
Jump to: navigation, search
(Unclassified: Base and/or Driver related)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Connector/OpenOffice.org development issues to discuss with OOo team =
+
#REDIRECT [[Database/Drivers/MySQL Native/Known Problems]]
 
+
== 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.
+
 
+
-- 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 ===
+
 
+
[http://dev.mysql.com/doc/refman/5.1/en/time.html|MySQL's 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 [http://dev.mysql.com/doc/refman/5.1/en/other-vendor-data-types.html 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.
+

Latest revision as of 08:52, 8 January 2009

Personal tools