Apache OpenOffice Wiki - User contributions [en]

Database/Drivers/MySQL Native/Known Problems

2009-05-06T16:10:13Z

Nixnutz: /* Copying tables does not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables does not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

INSERT INTO all_types (id , col1 , col2 , col3 , col4 , col5 , col6 , col7 , col8 , col9 , col10 , col11 , col12 , col13 , col14 , col15 , col16 , col17 , col18 , col19 , col20 , col21 , col22 , col23 , col24 , col25 , col26 , col27 , col28 , col29 , col30 , col31 , col32 , col33 , col34 , col35 , col36 , col37 , col38 , col39 , col40 , col41 , col42 , col43 , col44 , col45 , col46 , col47 , col48 , col49 , col50 , col51 , col52 , col53 , col54 , col55 , col56 , col57 , col58 , col59 , col60 , col61 , col62 , col63 , col64 , col65 , col66 , col67 , col68 , col69 , col70 , col71 , col72 , col73 , col74 , col75 , col76 , col77 , col78 , col79 , col80 , col81 , col82 , col83 , col84 , col85 , col86 , col87 , col88 , col89 , col90 , col91 , col92 , col93 , col94 , col95 , col96 , col97 , col98 , col99 , col100 , col101 , col102 , col103 , col104 , col105 , col106 , col107 , col108 , col109 , col110 , col111 , col112 , col113 , col114 , col115 , col116 , col117 , col118 , col119 , col120 , col121 , col122 , col123 , col124 , col125 , col126 , col127 , col128 , col129 , col130 , col131) VALUES ('1' , '0' , '1' , '0' , '0' , '127' , '127' , '12' , '3' , '255' , '1' , '1' , '2' , '3' , '-32768' , '32767' , '-32768' , '-32768' , '65535' , '123' , '123' , '-8388608' , '-8388608' , '2' , '2' , '16777215' , '1677721' , '2147483647' , '2147483647' , '3' , '4294967295' , '1' , '1' , '-9223372036854775808' , '-9223372036854775808' , '18446744073709551615' , '18446744073709551615' , '2' , '-1.01' , '-1.01' , '1.01' , '1.01' , '1.01' , '1.01' , '-1.01' , '-1.01' , '1.01' , '1.01' , '1.01' , '-1.01' , '-1.01' , '1.01' , '1.01' , '1.01' , '2009-02-09' , '2009-02-12' , '2009-02-12' , '2009-02-09 20:05:43' , '2009-02-12 17:49:21' , '2009-02-12 17:49:21' , '2038-01-09 03:14:07' , '-838:59:59' , '838:59:59' , '-838:59:59' , '1901' , '1902' , '2009' , '1' , '1' , 'a' , 'a' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'abc' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'a' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes' , 'yes')

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
** JDBC: same
* BIT [original] to VARCHAR [copy]: wrong data
** JDBC: no issue
* MEDIUMINT to VARCHAR conversion: wrong data, likely poor performance for users
** JDBC: no issue
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
** JDBC: same issue
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
** JDBC: YEAR to DATE
* TINYTEXT to VARCHAR(255): should be safe
** JDBC: same conversion
* TINYBLOB to VARBINARY(255): should be safe
** JDBC: TINYBLOB to BINARY(255) - identical
* BITINT(20) to BIGINT(19): should be safe
** JDBC: same conversion
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
** JDBC: not tested
* FLOAT/DOUBLE: wrong data, fraction lost
** JDBC: worse - no data copied for any column!
* All types: DEFAULT values lost, if the default value is not NULL.
** JDBC: same issue
* All string types: CHARACTER SET lost
** JDBC: same issue (because not supported by Base)
* All string types: COLLATION lost
** JDBC: same issue (because not supported by Base)
* Most/All numeric types: UNSIGNED not copied - usually combined with wrong data for min/max, kind of overflow?
** JDBC: wrong SQL, columns cannot be copied at all
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific
** JDBC: same

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
--> col1 - col3: wrong data - <something> -> 0
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
--> col9 - wrong data: 255 -> -1 ([UN]SIGNED overflow?)
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
--> col18 - wrong data: 65535 -> -1 ([UN]SIGNED overflow?)
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
--> col25 - wrong data -> 16777215 -> 1677721
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
--> col30 - wrong data - 4294967295 -> -1 ([UN]SIGNED overflow?)
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
--> col35, col36: wrong data: 1844...bignumber...615 -> -1 ([UN]SIGNED overflow)
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col38, col39, col40: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
--> col42, col43: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col44 - col47: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

=== BOOLEAN -> TINYINT conversion ===

As outlined in [[Database/Drivers/MySQL_Native/Known_Problems/Fixed#BOOLEAN_-.3E_TINYINT_conversion|the original item]] with the same title, MySQL does not really know the type BOOLEAN, but implicitly converts columns created as BOOLEAN to TINYINT(1). C/J implicitly converts TINYINT(1) to BOOLEAN, C/OOo doesn't. As a consequence, to the user it looks as if a column created as BOOLEAN silently changes its type after creation.

We should fix this, by either disallowing BOOLEAN as type in OOo, or by also silently interpreting TINYINT(1) as BOOLEAN.

Severity: 1.1

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

Database/Drivers/MySQL Native/Known Problems

2009-05-06T14:58:21Z

Nixnutz: /* Copying tables does not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables does not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
** JDBC: same
* BIT [original] to VARCHAR [copy]: wrong data
** JDBC: no issue
* MEDIUMINT to VARCHAR conversion: wrong data, likely poor performance for users
** JDBC: no issue
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
** JDBC: same issue
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
** JDBC: YEAR to DATE
* TINYTEXT to VARCHAR(255): should be safe
** JDBC: same conversion
* TINYBLOB to VARBINARY(255): should be safe
** JDBC: TINYBLOB to BINARY(255) - identical
* BITINT(20) to BIGINT(19): should be safe
** JDBC: same conversion
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
** JDBC: not tested
* FLOAT/DOUBLE: wrong data, fraction lost
** JDBC: worse - no data copied for any column!
* All types: DEFAULT values lost, if the default value is not NULL.
** JDBC: same issue
* All string types: CHARACTER SET lost
** JDBC: same issue (because not supported by Base)
* All string types: COLLATION lost
** JDBC: same issue (because not supported by Base)
* Most/All numeric types: UNSIGNED not copied - usually combined with wrong data for min/max, kind of overflow?
** JDBC: wrong SQL, columns cannot be copied at all
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific
** JDBC: same

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
--> col1 - col3: wrong data - <something> -> 0
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
--> col9 - wrong data: 255 -> -1 ([UN]SIGNED overflow?)
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
--> col18 - wrong data: 65535 -> -1 ([UN]SIGNED overflow?)
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
--> col25 - wrong data -> 16777215 -> 1677721
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
--> col30 - wrong data - 4294967295 -> -1 ([UN]SIGNED overflow?)
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
--> col35, col36: wrong data: 1844...bignumber...615 -> -1 ([UN]SIGNED overflow)
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col38, col39, col40: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
--> col42, col43: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col44 - col47: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

=== BOOLEAN -> TINYINT conversion ===

As outlined in [[Database/Drivers/MySQL_Native/Known_Problems/Fixed#BOOLEAN_-.3E_TINYINT_conversion|the original item]] with the same title, MySQL does not really know the type BOOLEAN, but implicitly converts columns created as BOOLEAN to TINYINT(1). C/J implicitly converts TINYINT(1) to BOOLEAN, C/OOo doesn't. As a consequence, to the user it looks as if a column created as BOOLEAN silently changes its type after creation.

We should fix this, by either disallowing BOOLEAN as type in OOo, or by also silently interpreting TINYINT(1) as BOOLEAN.

Severity: 1.1

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

Database/Drivers/MySQL Native/Known Problems

2009-05-06T14:54:05Z

Nixnutz: /* Copying tables does not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables does not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
** JDBC: same
* BIT [original] to VARCHAR [copy]: wrong data
** JDBC: no issue
* MEDIUMINT to VARCHAR conversion: wrong data, likely poor performance for users
** JDBC: no issue
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
** JDBC: same issue
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details

* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19): should be safe
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
* FLOAT/DOUBLE: wrong data, fraction lost
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied - usually combined with wrong data for min/max, kind of overflow?
** JDBC - wrong SQL, columns cannot be copied at all
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
--> col1 - col3: wrong data - <something> -> 0
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
--> col9 - wrong data: 255 -> -1 ([UN]SIGNED overflow?)
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
--> col18 - wrong data: 65535 -> -1 ([UN]SIGNED overflow?)
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
--> col25 - wrong data -> 16777215 -> 1677721
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
--> col30 - wrong data - 4294967295 -> -1 ([UN]SIGNED overflow?)
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
--> col35, col36: wrong data: 1844...bignumber...615 -> -1 ([UN]SIGNED overflow)
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col38, col39, col40: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
--> col42, col43: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col44 - col47: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

=== BOOLEAN -> TINYINT conversion ===

As outlined in [[Database/Drivers/MySQL_Native/Known_Problems/Fixed#BOOLEAN_-.3E_TINYINT_conversion|the original item]] with the same title, MySQL does not really know the type BOOLEAN, but implicitly converts columns created as BOOLEAN to TINYINT(1). C/J implicitly converts TINYINT(1) to BOOLEAN, C/OOo doesn't. As a consequence, to the user it looks as if a column created as BOOLEAN silently changes its type after creation.

We should fix this, by either disallowing BOOLEAN as type in OOo, or by also silently interpreting TINYINT(1) as BOOLEAN.

Severity: 1.1

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

Database/Drivers/MySQL Native/Known Problems

2009-05-06T14:01:48Z

Nixnutz: /* Copying tables does not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables does not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: wrong data
* MEDIUMINT to VARCHAR conversion: wrong data, likely poor performance for users
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19): should be safe
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
* FLOAT/DOUBLE: wrong data, fraction lost
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied - usually combined with wrong data for min/max, kind of overflow?
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
--> col1 - col3: wrong data - <something> -> 0
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
--> col9 - wrong data: 255 -> -1 ([UN]SIGNED overflow?)
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
--> col18 - wrong data: 65535 -> -1 ([UN]SIGNED overflow?)
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
--> col25 - wrong data -> 16777215 -> 1677721
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
--> col30 - wrong data - 4294967295 -> -1 ([UN]SIGNED overflow?)
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
--> col35, col36: wrong data: 1844...bignumber...615 -> -1 ([UN]SIGNED overflow)
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col38, col39, col40: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
--> col42, col43: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col44 - col47: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

=== BOOLEAN -> TINYINT conversion ===

As outlined in [[Database/Drivers/MySQL_Native/Known_Problems/Fixed#BOOLEAN_-.3E_TINYINT_conversion|the original item]] with the same title, MySQL does not really know the type BOOLEAN, but implicitly converts columns created as BOOLEAN to TINYINT(1). C/J implicitly converts TINYINT(1) to BOOLEAN, C/OOo doesn't. As a consequence, to the user it looks as if a column created as BOOLEAN silently changes its type after creation.

We should fix this, by either disallowing BOOLEAN as type in OOo, or by also silently interpreting TINYINT(1) as BOOLEAN.

Severity: 1.1

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

Database/Drivers/MySQL Native/Known Problems

2009-05-06T13:59:29Z

Nixnutz: /* Copying tables may not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables does not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: wrong data
* MEDIUMINT to VARCHAR conversion: I do not want to know what that does with the data and how it impacts performance...
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19): should be safe
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
--> col1 - col3: wrong data - <something> -> 0
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
--> col9 - wrong data: 255 -> -1 ([UN]SIGNED overflow?)
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
--> col18 - wrong data: 65535 -> -1 ([UN]SIGNED overflow?)
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
--> col25 - wrong data -> 16777215 -> 1677721
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
--> col30 - wrong data - 4294967295 -> -1 ([UN]SIGNED overflow?)
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
--> col35, col36: wrong data: 1844...bignumber...615 -> -1 ([UN]SIGNED overflow)
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col38, col39, col40: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
--> col42, col43: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
--> col44 - col47: wrong data, fraction part is lost, e.g. -1.01 -> 1
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

=== BOOLEAN -> TINYINT conversion ===

As outlined in [[Database/Drivers/MySQL_Native/Known_Problems/Fixed#BOOLEAN_-.3E_TINYINT_conversion|the original item]] with the same title, MySQL does not really know the type BOOLEAN, but implicitly converts columns created as BOOLEAN to TINYINT(1). C/J implicitly converts TINYINT(1) to BOOLEAN, C/OOo doesn't. As a consequence, to the user it looks as if a column created as BOOLEAN silently changes its type after creation.

We should fix this, by either disallowing BOOLEAN as type in OOo, or by also silently interpreting TINYINT(1) as BOOLEAN.

Severity: 1.1

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

Database/Drivers/MySQL Native/Known Problems

2009-05-05T17:43:13Z

Nixnutz: /* Currency Value DECIMAL columns */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

===Was <strike>Currency Value</strike>, is DECIMAL columns ===

reported by Mechtilde

This note relate to 4.2. I can't input currency values. I get there 0.00.

(Chris): i can confirm similar behavior:

1. create a table with a decimal field with two decimal places (& pk) 
2. open the table and insert some values (f.e. currency) 
-> after leaving the row the input is changed to '0' 
(the same with every text or decimal field)
=> no senseful inserting is possible 

(Ulf): this is about DECIMAL not Currency. Works with DOUBLE.

Severity: required

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: may mess up the data...
* MEDIUMINT to VARCHAR conversion: I do not want to know what that does with the data and how it impacts performance...
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19): should be safe
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

=== <strike>fieldtype is changed after saving</strike> BOOLEAN -> TINYINT conversion ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: desired

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

(CLU): agree with FS .. every proposed type has to work, any unsupported type must not be shown

(Ulf): Not an error in C/C++. There is no boolean type in MySQL, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . MySQL accepts the keywords BOOLEAN, TRUE and FALSE. That is all. MySQL converts BOOLEAN into TINYINT(1). TRUE and FALSE are aliases for 1 and 0, respectively:

mysql> create table bool_test(col boolean default true);
Query OK, 0 rows affected (1.41 sec)
mysql> show warnings;
Empty set (0.03 sec)
mysql> show errors;
Empty set (0.00 sec)
mysql> show create table bool_test;
+-----------+--------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------+--------------------------------------------------------------------------------------------------+
| bool_test | CREATE TABLE `bool_test` (
`col` tinyint(1) DEFAULT '1'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-----------+--------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

(Ulf): Connector/C++ returns what you get when you create a BOOLEAN column. You get a TINYINT(1) in your database. Connector/C++ returns what you see when you check the schema definition of a table with a TINYINT(1) column: type tinyint. Connector/J seems to define TINYINT(1) == BOOLEAN. That means, Connector/J cannot distinguish between a numeric column TINYINT(1) and a TINYINT(1) column that is intended to be a BOOLEAN. If a user creates a TINYINT(1) column with Connector/J, Connector/J will report BOOLEAN. There is no solution for handling the MySQL Server data type alias BOOLEAN (= converted implicitly into TINYINT(1)). The only thing you can do it is either to disallow the usage of BOOLEAN or TINYINT(1) in Base (= in Connector/OO.org) to solve the lack of clarity.

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

TODO (Ulf): do we still/really have a problem here? Severity?
(Ulf): I cannot answer this. I do not know where Base would use them.

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

Database/Drivers/MySQL Native/Known Problems

2009-05-05T17:42:23Z

Nixnutz: /* Copying tables may not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

===<strike>Currency Value</strike> DECIMAL columns ===

reported by Mechtilde

This note relate to 4.2. I can't input currency values. I get there 0.00.

(Chris): i can confirm similar behavior:

1. create a table with a decimal field with two decimal places (& pk) 
2. open the table and insert some values (f.e. currency) 
-> after leaving the row the input is changed to '0' 
(the same with every text or decimal field)
=> no senseful inserting is possible 

(Ulf): this is about DECIMAL not Currency. Works with DOUBLE.

Severity: required

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: may mess up the data...
* MEDIUMINT to VARCHAR conversion: I do not want to know what that does with the data and how it impacts performance...
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19): should be safe
* ENUM(x) to ENUM - wrong SQL, enumeration list missing, very likely the same with SET
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

=== <strike>fieldtype is changed after saving</strike> BOOLEAN -> TINYINT conversion ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: desired

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

(CLU): agree with FS .. every proposed type has to work, any unsupported type must not be shown

(Ulf): Not an error in C/C++. There is no boolean type in MySQL, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . MySQL accepts the keywords BOOLEAN, TRUE and FALSE. That is all. MySQL converts BOOLEAN into TINYINT(1). TRUE and FALSE are aliases for 1 and 0, respectively:

mysql> create table bool_test(col boolean default true);
Query OK, 0 rows affected (1.41 sec)
mysql> show warnings;
Empty set (0.03 sec)
mysql> show errors;
Empty set (0.00 sec)
mysql> show create table bool_test;
+-----------+--------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------+--------------------------------------------------------------------------------------------------+
| bool_test | CREATE TABLE `bool_test` (
`col` tinyint(1) DEFAULT '1'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-----------+--------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

(Ulf): Connector/C++ returns what you get when you create a BOOLEAN column. You get a TINYINT(1) in your database. Connector/C++ returns what you see when you check the schema definition of a table with a TINYINT(1) column: type tinyint. Connector/J seems to define TINYINT(1) == BOOLEAN. That means, Connector/J cannot distinguish between a numeric column TINYINT(1) and a TINYINT(1) column that is intended to be a BOOLEAN. If a user creates a TINYINT(1) column with Connector/J, Connector/J will report BOOLEAN. There is no solution for handling the MySQL Server data type alias BOOLEAN (= converted implicitly into TINYINT(1)). The only thing you can do it is either to disallow the usage of BOOLEAN or TINYINT(1) in Base (= in Connector/OO.org) to solve the lack of clarity.

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

TODO (Ulf): do we still/really have a problem here? Severity?
(Ulf): I cannot answer this. I do not know where Base would use them.

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

Database/Drivers/MySQL Native/Known Problems

2009-05-05T17:38:38Z

Nixnutz: /* Copying tables may not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

===<strike>Currency Value</strike> DECIMAL columns ===

reported by Mechtilde

This note relate to 4.2. I can't input currency values. I get there 0.00.

(Chris): i can confirm similar behavior:

1. create a table with a decimal field with two decimal places (& pk) 
2. open the table and insert some values (f.e. currency) 
-> after leaving the row the input is changed to '0' 
(the same with every text or decimal field)
=> no senseful inserting is possible 

(Ulf): this is about DECIMAL not Currency. Works with DOUBLE.

Severity: required

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: may mess up the data...
* MEDIUMINT to VARCHAR conversion: I do not want to know what that does with the data and how it impacts performance...
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19)
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

=== <strike>fieldtype is changed after saving</strike> BOOLEAN -> TINYINT conversion ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: desired

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

(CLU): agree with FS .. every proposed type has to work, any unsupported type must not be shown

(Ulf): Not an error in C/C++. There is no boolean type in MySQL, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . MySQL accepts the keywords BOOLEAN, TRUE and FALSE. That is all. MySQL converts BOOLEAN into TINYINT(1). TRUE and FALSE are aliases for 1 and 0, respectively:

mysql> create table bool_test(col boolean default true);
Query OK, 0 rows affected (1.41 sec)
mysql> show warnings;
Empty set (0.03 sec)
mysql> show errors;
Empty set (0.00 sec)
mysql> show create table bool_test;
+-----------+--------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------+--------------------------------------------------------------------------------------------------+
| bool_test | CREATE TABLE `bool_test` (
`col` tinyint(1) DEFAULT '1'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-----------+--------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

(Ulf): Connector/C++ returns what you get when you create a BOOLEAN column. You get a TINYINT(1) in your database. Connector/C++ returns what you see when you check the schema definition of a table with a TINYINT(1) column: type tinyint. Connector/J seems to define TINYINT(1) == BOOLEAN. That means, Connector/J cannot distinguish between a numeric column TINYINT(1) and a TINYINT(1) column that is intended to be a BOOLEAN. If a user creates a TINYINT(1) column with Connector/J, Connector/J will report BOOLEAN. There is no solution for handling the MySQL Server data type alias BOOLEAN (= converted implicitly into TINYINT(1)). The only thing you can do it is either to disallow the usage of BOOLEAN or TINYINT(1) in Base (= in Connector/OO.org) to solve the lack of clarity.

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

TODO (Ulf): do we still/really have a problem here? Severity?
(Ulf): I cannot answer this. I do not know where Base would use them.

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

Database/Drivers/MySQL Native/Known Problems

2009-05-05T17:37:56Z

Nixnutz: /* Copying tables may not work properly */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo. A list of fixed problems is also [[Database/Drivers/MySQL_Native/Known_Problems/Fixed|available]].

== required for 1.0 release ==

=== On windows, the extension crashs on some systems ===

reported by FS on 2009-04-09

On some Windows systems, if you install and use the extension, it will crash OOo.

Severity: required

Reason: The extension ships an own version of <code>libmysql.dll</code>. When Windows loads the driver library (<code>mysqlc.uno.dll</code>), it also implicitly loads the <code>libmysql.dll</code>, which <code>mysqlc.uno.dll</code> is linked against. Unfortunately, Windows first searches in the folders specified by your <code>PATH</code> environment variable. If it finds a <code>libmysql.dll</code> in one of those folders, this one is used - no matter whether it is really compatible.

Suggested solutions:
* rename <code>libmysql.dll</code>, and link against this renamed version. Argh, not really.
* link <code>libmysql.dll</code> statically
* load libmysql.dll explicitly (using <code>LoadLibrary</code>). In this case, we would have control over where the lib is taken from
* make libmysql a managed assembly, having a identifer, and a version, which changes with every incompatible API/ABI change (and differs between the debug and the release version). In this case, Windows would ignore all libmysql.dll versions found in the <code>PATH</code> which do not proper version.

TODO (Andrey): fix

===<strike>Currency Value</strike> DECIMAL columns ===

reported by Mechtilde

This note relate to 4.2. I can't input currency values. I get there 0.00.

(Chris): i can confirm similar behavior:

1. create a table with a decimal field with two decimal places (& pk) 
2. open the table and insert some values (f.e. currency) 
-> after leaving the row the input is changed to '0' 
(the same with every text or decimal field)
=> no senseful inserting is possible 

(Ulf): this is about DECIMAL not Currency. Works with DOUBLE.

Severity: required

== Unclassified/TODO ==

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

TODO (Ulf): check what problems we actually have here, and how severe they are (compared with a connection vis ODBC/JDBC).

(Ulf) Create the following table on the MySQL prompt and clone it using Base. Compare the table that Base creates with the original one.

CREATE TABLE `all_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` bit(1) DEFAULT NULL,
`col2` bit(1) NOT NULL,
`col3` bit(5) NOT NULL,
`col4` bit(8) DEFAULT NULL,
`col5` tinyint(4) DEFAULT NULL,
`col6` tinyint(4) NOT NULL,
`col7` tinyint(4) NOT NULL DEFAULT '-1',
`col8` tinyint(1) DEFAULT NULL,
`col9` tinyint(3) unsigned DEFAULT NULL,
`col10` tinyint(3) unsigned zerofill DEFAULT NULL,
`col11` tinyint(1) DEFAULT NULL,
`col12` tinyint(1) NOT NULL,
`col13` tinyint(1) DEFAULT '0',
`col14` smallint(6) DEFAULT NULL,
`col15` smallint(6) NOT NULL,
`col16` smallint(6) NOT NULL DEFAULT '-1',
`col17` smallint(3) DEFAULT NULL,
`col18` smallint(5) unsigned DEFAULT NULL,
`col19` smallint(5) unsigned zerofill DEFAULT NULL,
`col20` smallint(5) unsigned zerofill DEFAULT '00101',
`col21` mediumint(9) DEFAULT NULL,
`col22` mediumint(9) NOT NULL,
`col23` mediumint(1) DEFAULT NULL,
`col24` mediumint(2) DEFAULT '12',
`col25` mediumint(8) unsigned DEFAULT NULL,
`col26` mediumint(8) unsigned zerofill DEFAULT NULL,
`col27` int(11) DEFAULT NULL,
`col28` int(11) NOT NULL,
`col29` int(1) DEFAULT NULL,
`col30` int(10) unsigned DEFAULT NULL,
`col31` int(4) unsigned zerofill DEFAULT NULL,
`col32` int(4) DEFAULT '-123',
`col33` bigint(20) DEFAULT NULL,
`col34` bigint(20) NOT NULL,
`col35` bigint(20) unsigned DEFAULT NULL,
`col36` bigint(20) unsigned DEFAULT NULL,
`col37` bigint(4) unsigned zerofill DEFAULT '10101',
`col38` float DEFAULT NULL,
`col39` float NOT NULL,
`col40` float unsigned DEFAULT NULL,
`col41` float(5,3) unsigned zerofill DEFAULT NULL,
`col42` float DEFAULT NULL,
`col43` float DEFAULT '1.01',
`col44` double DEFAULT NULL,
`col45` double NOT NULL,
`col46` double unsigned DEFAULT NULL,
`col47` double unsigned DEFAULT '1.123',
`col48` double(5,3) unsigned zerofill DEFAULT NULL,
`col49` decimal(10,0) DEFAULT NULL,
`col50` decimal(10,0) NOT NULL,
`col51` decimal(10,0) unsigned DEFAULT NULL,
`col52` decimal(5,3) unsigned zerofill DEFAULT NULL,
`col53` decimal(6,3) unsigned zerofill DEFAULT '034.560',
`col54` date DEFAULT NULL,
`col55` date NOT NULL,
`col56` date NOT NULL DEFAULT '2009-02-16',
`col57` datetime DEFAULT NULL,
`col58` datetime NOT NULL,
`col59` datetime NOT NULL DEFAULT '2009-02-12 21:36:54',
`col60` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`col61` time DEFAULT NULL,
`col62` time NOT NULL,
`col63` time DEFAULT '12:39:41',
`col64` year(4) DEFAULT NULL,
`col65` year(4) NOT NULL,
`col66` year(4) DEFAULT NULL,
`col67` year(2) DEFAULT NULL,
`col68` year(4) DEFAULT '2009',
`col69` char(1) DEFAULT NULL,
`col70` char(1) NOT NULL,
`col71` char(255) DEFAULT NULL,
`col72` binary(255) DEFAULT NULL,
`col73` char(254) NOT NULL,
`col74` char(254) NOT NULL DEFAULT 'abc',
`col75` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col76` char(215) CHARACTER SET utf8 NOT NULL,
`col77` char(215) CHARACTER SET utf8 NOT NULL DEFAULT 'Ulf',
`col78` char(255) CHARACTER SET utf8 DEFAULT NULL,
`col79` char(55) CHARACTER SET utf8 NOT NULL,
`col80` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col81` char(250) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT 'Wendel',
`col82` char(43) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`col83` char(123) CHARACTER SET ucs2 DEFAULT NULL,
`col84` binary(255) DEFAULT NULL,
`col85` binary(12) NOT NULL,
`col86` char(14) DEFAULT 'Andrey',
`col87` binary(25) DEFAULT NULL,
`col88` varchar(10) DEFAULT NULL,
`col89` varbinary(10) DEFAULT NULL,
`col90` varchar(7) NOT NULL,
`col91` varchar(255) DEFAULT 'Good night twitter. BTW, go MySQL!',
`col92` varchar(11) CHARACTER SET utf8 DEFAULT NULL,
`col93` varchar(11) CHARACTER SET ascii DEFAULT 'Hristov',
`col94` varchar(12) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`col95` varbinary(13) DEFAULT NULL,
`col96` varbinary(14) NOT NULL,
`col97` binary(1) DEFAULT NULL,
`col98` varbinary(1) DEFAULT NULL,
`col99` varbinary(2) NOT NULL,
`col100` varbinary(20) NOT NULL DEFAULT 'Lawrin',
`col101` tinyblob,
`col102` tinytext,
`col103` tinytext NOT NULL,
`col104` tinytext,
`col105` tinyblob,
`col106` tinytext CHARACTER SET utf8,
`col107` tinytext CHARACTER SET utf8 COLLATE utf8_bin,
`col108` mediumblob,
`col109` mediumblob NOT NULL,
`col110` mediumtext,
`col111` mediumblob,
`col112` mediumtext NOT NULL,
`col113` mediumtext CHARACTER SET utf8,
`col114` mediumtext CHARACTER SET utf8 COLLATE utf8_bin,
`col115` longblob,
`col116` longblob NOT NULL,
`col117` longtext,
`col118` longblob,
`col119` longtext NOT NULL,
`col120` longtext CHARACTER SET utf8,
`col121` longtext CHARACTER SET utf8 COLLATE utf8_bin,
`col122` enum('yes','no') DEFAULT NULL,
`col123` enum('yes','no') CHARACTER SET binary DEFAULT NULL,
`col124` enum('yes','no') NOT NULL,
`col125` enum('yes','no','not sure') NOT NULL,
`col126` enum('yes','no','buy') NOT NULL DEFAULT 'buy',
`col127` set('yes','no') DEFAULT NULL,
`col128` set('yes','no') CHARACTER SET binary DEFAULT NULL,
`col129` set('yes','no') CHARACTER SET ascii DEFAULT NULL,
`col130` set('yes','no') CHARACTER SET ascii DEFAULT 'yes',
`col131` set('yes','no','ascii') CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

(Ulf) Issue summary:

* Precision changes can usually be ignored, because most of the time it is a "display width" for MySQL, not a column value range limitation, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . The "precision" seems correct whenever it has to be.
* BIT [original] to VARCHAR [copy]: may mess up the data...
* MEDIUMINT to VARCHAR conversion: I do not want to know what that does with the data and how it impacts performance...
* TIMESTAMP to DATETIME conversion: safe with regards to data, but TIMESTAMP columns have a special semantics in MySQL - "By default, the first TIMESTAMP column in a table is automatically set to the date and time of the most recent operation [...]"
* YEAR to VARCHAR conversion: safe with regards to the data, but value range is wider and YEAR(2) DEFAULT 70 means default 1970... glory details
* TINYTEXT to VARCHAR(255): should be safe
* TINYBLOB to VARBINARY(255): should be safe
* BITINT(20) to BIGINT(19)
* All types: DEFAULT values lost, if the default value is not NULL.
* All string types: CHARACTER SET lost
* All string types: COLLATION lost
* Most/All numeric types: UNSIGNED not copied
* Most/All numeric types: ZEROFILL not copied - should be ignored, MySQL specific

(Ulf) Detailed results:

o OK
x some kind of trouble

o `id` int(10) NOT NULL AUTO_INCREMENT,
--> type changes BIT -> VARCHAR()
x `col1` varchar(1) DEFAULT NULL,
x `col2` varchar(1) NOT NULL,
x `col3` varchar(5) NOT NULL,
x `col4` varchar(8) DEFAULT NULL,
--> Precision wrong TINYINT(n) -> TINYINT(3), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col5` tinyint(3) DEFAULT NULL,
x `col6` tinyint(3) NOT NULL,
x `col7` tinyint(3) NOT NULL,
x `col8` tinyint(3) DEFAULT NULL,
x `col9` tinyint(3) DEFAULT NULL,
x `col10` tinyint(3) DEFAULT NULL,
x `col11` tinyint(3) DEFAULT NULL,
x `col12` tinyint(3) NOT NULL,
x `col13` tinyint(3) DEFAULT NULL,
--> Precision wrong SMALLINT(n) -> SMALLINT(5), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col14` smallint(5) DEFAULT NULL,
x `col15` smallint(5) NOT NULL,
x `col16` smallint(5) NOT NULL,
x `col17` smallint(5) DEFAULT NULL,
x `col18` smallint(5) DEFAULT NULL,
x `col19` smallint(5) DEFAULT NULL,
x `col20` smallint(5) DEFAULT NULL,
--> Type wrong: MEDIUMINT -> VARCHAR, always
--> Precision wrong: MEDIUMINT(n) -> VARCHAR(7), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col21` varchar(7) DEFAULT NULL,
x `col22` varchar(7) NOT NULL,
x `col23` varchar(7) DEFAULT NULL,
x `col24` varchar(7) DEFAULT NULL,
x `col25` varchar(7) DEFAULT NULL,
x `col26` varchar(7) DEFAULT NULL,
--> Precision wrong: INT(n) -> INT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col27` int(10) DEFAULT NULL,
x `col28` int(10) NOT NULL,
x `col29` int(10) DEFAULT NULL,
x `col30` int(10) DEFAULT NULL,
x `col31` int(10) DEFAULT NULL,
x `col32` int(10) DEFAULT NULL,
--> Precision wrong: BIGINT(20) -> BIGINT(19), always
--> Possible data loss due to 20->19 (!)
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col33` bigint(19) DEFAULT NULL,
x `col34` bigint(19) NOT NULL,
x `col35` bigint(19) DEFAULT NULL,
x `col36` bigint(19) DEFAULT NULL,
x `col37` bigint(19) DEFAULT NULL,
--> Precision wrong: FLOAT -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col38` float(10,0) DEFAULT NULL,
x `col39` float(10,0) NOT NULL,
x `col40` float(10,0) DEFAULT NULL,
x `col41` float(5,3) DEFAULT NULL,
x `col42` float(10,0) DEFAULT NULL,
x `col43` float(10,0) DEFAULT NULL,
--> Precision wrong: DOUBLE -> FLOAT(10), always
--> DEFAULT values lost
--> UNSIGNED lost
--> ZEROFILL lost
x `col44` double(17,0) DEFAULT NULL,
x `col45` double(17,0) NOT NULL,
x `col46` double(17,0) DEFAULT NULL,
x `col47` double(17,0) DEFAULT NULL,
x `col48` double(5,3) DEFAULT NULL,
o `col49` decimal(10,0) DEFAULT NULL,
o `col50` decimal(10,0) NOT NULL,
--> UNSIGNED lost
--> ZEROFILL lost
x `col51` decimal(10,0) DEFAULT NULL,
x `col52` decimal(5,3) DEFAULT NULL,
x `col53` decimal(6,3) DEFAULT NULL,
o `col54` date DEFAULT NULL,
o `col55` date NOT NULL,
--> DEFAULT values lost
x `col56` date NOT NULL,
o `col57` datetime DEFAULT NULL,
o `col58` datetime NOT NULL,
x `col59` datetime NOT NULL,
--> TIMESTAMP -> DATETIME (safe value range but wrong semantics)
x `col60` datetime NOT NULL,
o `col61` time DEFAULT NULL,
o `col62` time NOT NULL,
--> DEFAULT values lost
x `col63` time DEFAULT NULL,
--> YEAR->VARCHAR (safe value range but wrong semantics)
--> DEFAULT values lost
x `col64` varchar(4) DEFAULT NULL,
x `col65` varchar(4) NOT NULL,
x `col66` varchar(4) DEFAULT NULL,
x `col67` varchar(2) DEFAULT NULL,
x `col68` varchar(4) DEFAULT NULL,
o `col69` char(1) DEFAULT NULL,
o `col70` char(1) NOT NULL,
o `col71` char(255) DEFAULT NULL,
o `col72` binary(255) DEFAULT NULL,
o `col73` char(254) NOT NULL,
--> DEFAULT values lost
x `col74` char(254) NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
--> DEFAULT values lost
x `col75` char(255) DEFAULT NULL,
x `col76` char(215) NOT NULL,
x `col77` char(215) NOT NULL,
x `col78` char(255) DEFAULT NULL,
x `col79` char(55) NOT NULL,
x `col80` char(250) DEFAULT NULL,
x `col81` char(250) DEFAULT NULL,
x `col82` char(43) NOT NULL,
x `col83` char(123) DEFAULT NULL,
o `col84` binary(255) DEFAULT NULL,
o `col85` binary(12) NOT NULL,
--> DEFAULT values lost
x `col86` char(14) DEFAULT NULL,
o `col87` binary(25) DEFAULT NULL,
o `col88` varchar(10) DEFAULT NULL,
o `col89` varbinary(10) DEFAULT NULL,
o `col90` varchar(7) NOT NULL,
--> DEFAULT values lost
x `col91` varchar(255) DEFAULT NULL,
x `col92` varchar(11) DEFAULT NULL,
x `col93` varchar(11) DEFAULT NULL,
x `col94` varchar(12) DEFAULT NULL,
o `col95` varbinary(13) DEFAULT NULL,
o `col96` varbinary(14) NOT NULL,
o `col97` binary(1) DEFAULT NULL,
o `col98` varbinary(1) DEFAULT NULL,
o `col99` varbinary(2) NOT NULL,
--> DEFAULT values lost
x `col100` varbinary(20) NOT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col101` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
x `col102` varchar(255) DEFAULT NULL,
x `col103` varchar(255) NOT NULL,
x `col104` varchar(255) DEFAULT NULL,
--> TINYBLOB -> VARBINARY(255)
x `col105` varbinary(255) DEFAULT NULL,
--> TINYTEXT -> VARCHAR(255)
--> CHARACTER SET lost
--> COLLATION lost
x `col106` varchar(255) DEFAULT NULL,
x `col107` varchar(255) DEFAULT NULL,
o `col108` mediumblob,
o `col109` mediumblob NOT NULL,
o `col110` mediumtext,
o `col111` mediumblob,
o `col112` mediumtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col113` mediumtext,
x `col114` mediumtext,
o `col115` longblob,
o `col116` longblob NOT NULL,
o `col117` longtext,
o `col118` longblob,
o `col119` longtext NOT NULL,
--> CHARACTER SET lost
--> COLLATION lost
x `col120` longtext,
x `col121` longtext,
o PRIMARY KEY (`id`)
o) ENGINE=InnoDB DEFAULT CHARSET=latin1

=== <strike>fieldtype is changed after saving</strike> BOOLEAN -> TINYINT conversion ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: desired

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

(CLU): agree with FS .. every proposed type has to work, any unsupported type must not be shown

(Ulf): Not an error in C/C++. There is no boolean type in MySQL, see http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html . MySQL accepts the keywords BOOLEAN, TRUE and FALSE. That is all. MySQL converts BOOLEAN into TINYINT(1). TRUE and FALSE are aliases for 1 and 0, respectively:

mysql> create table bool_test(col boolean default true);
Query OK, 0 rows affected (1.41 sec)
mysql> show warnings;
Empty set (0.03 sec)
mysql> show errors;
Empty set (0.00 sec)
mysql> show create table bool_test;
+-----------+--------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------+--------------------------------------------------------------------------------------------------+
| bool_test | CREATE TABLE `bool_test` (
`col` tinyint(1) DEFAULT '1'
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-----------+--------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

(Ulf): Connector/C++ returns what you get when you create a BOOLEAN column. You get a TINYINT(1) in your database. Connector/C++ returns what you see when you check the schema definition of a table with a TINYINT(1) column: type tinyint. Connector/J seems to define TINYINT(1) == BOOLEAN. That means, Connector/J cannot distinguish between a numeric column TINYINT(1) and a TINYINT(1) column that is intended to be a BOOLEAN. If a user creates a TINYINT(1) column with Connector/J, Connector/J will report BOOLEAN. There is no solution for handling the MySQL Server data type alias BOOLEAN (= converted implicitly into TINYINT(1)). The only thing you can do it is either to disallow the usage of BOOLEAN or TINYINT(1) in Base (= in Connector/OO.org) to solve the lack of clarity.

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

TODO (Ulf): do we still/really have a problem here? Severity?
(Ulf): I cannot answer this. I do not know where Base would use them.

== Post-1.0 ==

=== Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

clu: works also wrong with native mysql driver -> works fine with odbc driver

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: later

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27

http://pastebin.com/m75809

Severity: later

Reason: unknown

=== getWarnings() (C/OOo) ===

reported by FS on 2009-01-29

C/OOo's getWarnings is implemented as dummy only. It should at least retrieve the warnings from the underlying C/C++ connection, and concert them to css.sdbc.SQLWarnings as appropriate.

Severity: later

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)

supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject is not used.

getExportedKeys seems to be used in the form wizard, to properly set up sub forms. Given that this currently [http://www.openoffice.org/issues/show_bug.cgi?id=101463 doesn't work for MySQL/JDBC], either, this does qualify as severity 1.x.

The other ones are not used.

Severity: 1.1

Database/Drivers/MySQL Native/Known Problems

2009-05-05T14:33:19Z

Nixnutz: /* getImportedKeys()/getExportedKeys() */

Database/Drivers/MySQL Native/Known Problems

2009-05-05T14:31:56Z

Nixnutz: /* fieldtype is changed after saving BOOLEAN -> TINYINT conversion */

Database/Drivers/MySQL Native/Known Problems

2009-05-05T14:31:40Z

Nixnutz: /* fieldtype is changed after saving BOOLEAN -> TINYINT conversion */

Database/Drivers/MySQL Native/Known Problems

2009-05-05T14:28:55Z

Nixnutz: /* fieldtype is changed after saving */

Database/Drivers/MySQL Native/Known Problems

2009-05-05T11:00:11Z

Nixnutz: /* DatabseMetaData::getColumns() DECIMAL_DIGITS */

Database/Drivers/MySQL Native/Known Problems/Fixed

2009-05-05T11:00:09Z

Nixnutz:

{{DISPLAYTITLE:MySQL Native Driver: Fixed Problems}}

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

Ulf: can not reproduce with 1.0 alpha

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

Ulf: works with 1.0 alpha

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: fixed in current version

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

(CLU): please fix this issue preferred, because this is a potential 'showstopper' for even an alpha release and also hinder further testing.

(Mechtilde) After testing the alpha version I found this problem only with currency values. It stays as 0.00. In my test all other values work

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: fixed in current version

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)

=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: fixed in current version

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

(CLU): no new column is added, just the pk is changed in table edit view (in this case the field is empty) .. sure the content must be unique, else i would await an error message ;)

clu: .. and error message comes ;)

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: fixed in current version

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

(CLU): cannot check at the moment .. but i do not understand, what an invalid error message has to do with wrong lenght of varchar columns? do you think it could have caused this message?

=== 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.

Severity: undecided

FS: works as expected now. As Ulf and /me agreed, C/OOo will not expose the I_S at all.

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish ? java assertion list appears

Severity: fixed in current version

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

FS: Fixed. Since the Connector/OOo does not expose the INFORMATION_SCHEMA anymore, the wizard cannot pick it ...

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: fixed in current version

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

FS: fixed with the usage of the SDBCX wrapper, which is also employed for MySQL via ODBC/JDBC.

=== 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 shown.

Severity: desired

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.

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: fixed in current version

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

(CLU): as the driver should work as good as jdbc/odbc driver or better, we have to think about a solution in future versions (how about deleting and creating new?)

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: fixed in current version

FS: fixed with the usage of the SDBCX wrapper driver. Note that for undprivileged users (which cannot select from the users table), there's still the error message that user administration is not supported. This is actually wrong, but the error of the missing privileges is not propagated to the user here.

=== 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

Severity: required

FS: fixed meanwhile. Was most probably a duplicate of the other "can't insert data" issue

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

FS: The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

FS: fixed meanwhile. Probably was a duplicate of another issue, which was caused by wrong translations from C/C++'s sql::SQLException to C/OOo's css.sdbc.SQLException.

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

FS: fixed. Replaced all occurrences of OUString::createFromAscii, which was applied to a C/Cpp-provided string, with proper decoding assuming UTF-8.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

FS: fixed in a recent build, where Andrey's normalization of data types landed

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: fixed in current version

FS: Fixed in a recent build, where Andrey's performance fixes to C/C++'s result sets landed. Now the performance is on the same level as with the JDBC driver, further performance improvements will happen on the Base side, independent from the MySQL native driver.

=== Creating view not possible ===

create any view in design mode & save -> error message: 'CREATE VIEW command denied to user ..'

Severity: desired

FS: cannot reproduce in current build (as of 2009-04-30)

=== OPreparedStatement::getMetaData is not implemented ===

OPreparedStatement::getMetaData is not implemented currently. Per API spec, it is expected to retrieve the meta data of the result set which the prepared statement would, well, result in, when executed. There are places in the API (SingleSelectQueryComposer, for instance), which make use of this functionality, and might fail.

Severity: desired

=== Exception not converted ===

reported by Ulf on 2009-01-27

sql.SQLException not handled in C/OO.org and not converted into SQLException.

.MSG: Calling DatabaseMetaData.getImportedKeys
ERROR: Unexpected Exception exception type not found: sql.SQLException

Same for getIndex().

Severity: required

Reason: C/OO.org bug

FS: Raised the severity to "required", since on Unix platforms, throwing an exception which is not part of the method's exception specification will abort the process.

=== 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, and also display all those tables.

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

Severity: desired

FS: classified as feature by now ...

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

FS: Base doesn't really want a particular logic. If a database supports only schemas, that's fine, if it supports only catalogs, that's fine, if it supports both, that's fine, too. The only requirement is that the responses of the driver should be consistent.
The fact that the JDBC driver exposes MySQL databases as catalogs is, finally, an implementation detail of the JDBC driver. As far as I know, the decision to mirror MySQL databases as schema instead of catalogs is younger than the current C/J.

I'd say we stay with C/OOo mapping databases to schemas, I seem to remember from talks with Georg that this is the preferred way nowadays.

FS: as agreed with Ulf, the current situation, where MySQL DBs are mapped to schemas, is perfectly okay.

=== getWarnings() (C/C++) ===

reported by Ulf on 2009-01-26

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

FS: fixed in current version (C/C++ GA), according to Ulf

=== Get the Mac version running ===

There's currently no working Mac version (though versions for Windows, Solaris Sparc, Solaris x86, Linux 32bit). Since Mac is one of the standard platforms of OOo, this needs to be fixed ...

Severity: required

FS: Building the lib is no problem, and I also managed to employ the install_name_tool to fix the lib paths in the C/OOo and C/C++ libs, but somehow ... this things doesn't register so far ...

Database/Drivers/MySQL Native/Known Problems

2009-05-05T10:59:19Z

Nixnutz: /* DatabseMetaData::getColumns() COLUMN_SIZE */

Database/Drivers/MySQL Native/Known Problems/Fixed

2009-05-05T10:59:17Z

Nixnutz:

{{DISPLAYTITLE:MySQL Native Driver: Fixed Problems}}

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

Ulf: works with 1.0 alpha

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: fixed in current version

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

(CLU): please fix this issue preferred, because this is a potential 'showstopper' for even an alpha release and also hinder further testing.

(Mechtilde) After testing the alpha version I found this problem only with currency values. It stays as 0.00. In my test all other values work

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: fixed in current version

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)

=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: fixed in current version

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

(CLU): no new column is added, just the pk is changed in table edit view (in this case the field is empty) .. sure the content must be unique, else i would await an error message ;)

clu: .. and error message comes ;)

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: fixed in current version

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

(CLU): cannot check at the moment .. but i do not understand, what an invalid error message has to do with wrong lenght of varchar columns? do you think it could have caused this message?

=== 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.

Severity: undecided

FS: works as expected now. As Ulf and /me agreed, C/OOo will not expose the I_S at all.

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish ? java assertion list appears

Severity: fixed in current version

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

FS: Fixed. Since the Connector/OOo does not expose the INFORMATION_SCHEMA anymore, the wizard cannot pick it ...

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: fixed in current version

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

FS: fixed with the usage of the SDBCX wrapper, which is also employed for MySQL via ODBC/JDBC.

=== 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 shown.

Severity: desired

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.

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: fixed in current version

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

(CLU): as the driver should work as good as jdbc/odbc driver or better, we have to think about a solution in future versions (how about deleting and creating new?)

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: fixed in current version

FS: fixed with the usage of the SDBCX wrapper driver. Note that for undprivileged users (which cannot select from the users table), there's still the error message that user administration is not supported. This is actually wrong, but the error of the missing privileges is not propagated to the user here.

=== 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

Severity: required

FS: fixed meanwhile. Was most probably a duplicate of the other "can't insert data" issue

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

FS: The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

FS: fixed meanwhile. Probably was a duplicate of another issue, which was caused by wrong translations from C/C++'s sql::SQLException to C/OOo's css.sdbc.SQLException.

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

FS: fixed. Replaced all occurrences of OUString::createFromAscii, which was applied to a C/Cpp-provided string, with proper decoding assuming UTF-8.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

FS: fixed in a recent build, where Andrey's normalization of data types landed

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: fixed in current version

FS: Fixed in a recent build, where Andrey's performance fixes to C/C++'s result sets landed. Now the performance is on the same level as with the JDBC driver, further performance improvements will happen on the Base side, independent from the MySQL native driver.

=== Creating view not possible ===

create any view in design mode & save -> error message: 'CREATE VIEW command denied to user ..'

Severity: desired

FS: cannot reproduce in current build (as of 2009-04-30)

=== OPreparedStatement::getMetaData is not implemented ===

OPreparedStatement::getMetaData is not implemented currently. Per API spec, it is expected to retrieve the meta data of the result set which the prepared statement would, well, result in, when executed. There are places in the API (SingleSelectQueryComposer, for instance), which make use of this functionality, and might fail.

Severity: desired

=== Exception not converted ===

reported by Ulf on 2009-01-27

sql.SQLException not handled in C/OO.org and not converted into SQLException.

.MSG: Calling DatabaseMetaData.getImportedKeys
ERROR: Unexpected Exception exception type not found: sql.SQLException

Same for getIndex().

Severity: required

Reason: C/OO.org bug

FS: Raised the severity to "required", since on Unix platforms, throwing an exception which is not part of the method's exception specification will abort the process.

=== 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, and also display all those tables.

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

Severity: desired

FS: classified as feature by now ...

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

FS: Base doesn't really want a particular logic. If a database supports only schemas, that's fine, if it supports only catalogs, that's fine, if it supports both, that's fine, too. The only requirement is that the responses of the driver should be consistent.
The fact that the JDBC driver exposes MySQL databases as catalogs is, finally, an implementation detail of the JDBC driver. As far as I know, the decision to mirror MySQL databases as schema instead of catalogs is younger than the current C/J.

I'd say we stay with C/OOo mapping databases to schemas, I seem to remember from talks with Georg that this is the preferred way nowadays.

FS: as agreed with Ulf, the current situation, where MySQL DBs are mapped to schemas, is perfectly okay.

=== getWarnings() (C/C++) ===

reported by Ulf on 2009-01-26

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

FS: fixed in current version (C/C++ GA), according to Ulf

=== Get the Mac version running ===

There's currently no working Mac version (though versions for Windows, Solaris Sparc, Solaris x86, Linux 32bit). Since Mac is one of the standard platforms of OOo, this needs to be fixed ...

Severity: required

FS: Building the lib is no problem, and I also managed to employ the install_name_tool to fix the lib paths in the C/OOo and C/C++ libs, but somehow ... this things doesn't register so far ...

Database/Drivers/MySQL Native/Known Problems

2009-05-05T09:48:41Z

Nixnutz: /* Currency Value */

Database/Drivers/MySQL Native/Beta

2009-04-09T13:45:37Z

Nixnutz: /* Known Bugs */

== Introduction ==

MySQL Connector/OpenOffice.org is a MySQL driver for [http://www.openoffice.org/ OpenOffice.org]. It can be used to connect from OpenOffice.org 3.1 to a MySQL server 5.1 or newer.

Before MySQL Connector/OpenOffice.org became available you'd have to use [http://dev.mysql.com/downloads/connector/j/ MySQL Connector/J (JDBC)] or [http://dev.mysql.com/downloads/connector/odbc/ MySQL Connector/ODBC] to connect to a MySQL server.

Therefore the driver is also referred to as a native driver in the context of OpenOffice.org. The term native driver clashes with the MySQL definition of a native driver. MySQL Connector/OpenOffice.org does not implement the MySQL Client Server protocol. Technically speaking the MySQL Connector/OpenOffice.org is implemented as a proxy on top of the [http://dev.mysql.com/doc/refman/5.1/en/connector-cpp.html MySQL Connector/C++].

The driver is delivered as an OpenOffice.org extension.

=== Advantages ===

Using MySQL Connector/OpenOffice.org has the following advantages:

* Easy installation through the OpenOffice.org Extension Manager.
* Seamless integration into OpenOffice.org.
* No need to go through an additional Connector installation routine (ODBC/JDBC)
* No need to configure or register an additional Connector (ODBC)
* No need to install or configure a driver manager (ODBC)

=== Status ===

Please note, the MySQL Connector/OpenOffice.org is released as an alpha version. We do not recommend using the driver in production environments or systems with critical data. Please note, official support is not available.

== Installation ==

=== Install or upgrade to OpenOffice.org 3.1 ===

OpenOffice.org 3.1 is available as a Release Candidate at [http://download.openoffice.org/next/index.html http://download.openoffice.org/next/index.html]. The driver does not work together with any other OpenOffice.org version.

Caution: The installation wizard of OpenOffice.org 3.1 will remove older OpenOffice.org installations from your system by default. If you wo not want this, check out for the corresponding settings of the installation wizard.

=== Download MySQL Connector/OpenOffice.org ===

The alpha version is available as a QA build from [ftp://qa-upload.services.openoffice.org/MySQLNative/ ftp://qa-upload.services.openoffice.org/MySQLNative/] -

The extension is available for the following platforms:
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-windows-x86-32bit.oxt Windows x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-linux-x86-32bit.oxt Linux x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-sparc-32bit.oxt Solaris SPARC, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-x86-32bit.oxt Solaris x86, 32bit]

Save the download to a location of your choice, for example <code>My Documents</code> or <code>~/Documents</code>.

=== Installing the extension ===

Add the <code>.oxt</code> extension through the Extension Manager of OpenOffice.org. In OpenOffice.org, select <code>Tools, Extension Manager...</code> and specify the <code>.oxt</code> file as a new extension. When done, MySQL Connector/OpenOffice.org should show up as a new extension under <code>My Extensions</code>.
: [[Image:Conn_ooo_alpha_extensions.jpg]]

Restart OpenOffice.org to complete the installation.

== Getting Started: Connecting to MySQL ==

MySQL Connector/OpenOffice.org allows you to access the MySQL Server and its schemata from the OpenOffice.org suite.

The following example demonstrates the creation of a new OpenOffice.org Base database which uses a local MySQL Server for storage and the new connector for connecting.

=== Select the database ===

Create a new database (<code>File, New, Database</code>). This starts a wizard that allows you to create a new, open an existing, or connect to existing database. Select the latter option.

From the drop-down list, select <code>MySQL</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard1.jpg]]

=== Select the type of the driver ===

You can use three different MySQL drivers for connecting to MySQL from OpenOffice.org. You can choose a generic ODBC or JDBC connection method or the native driver. Select <code>Connect native</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard2.jpg]]

=== Setting up the database connection ===

Set up the database connection. Put the schema (database) you want to connect to into <code>Name of the database</code>. Enter the URL (host name), Port and Socket of your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard3.jpg]]

=== Fill in user credentials ===

Provide the user credentials for connecting to your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard4.jpg]]

=== Save and proceed ===

Finish the wizard. All defaults are a safe choice. Click <code>Finish >></code>.

[[Image:Conn_ooo_alpha_wizard5.jpg]]

== Getting Started: Usage Examples ==
=== Listing Tables ===
In the Database area of the Base main window, select Tables. If this is the first time you're accessing the database you'll be prompted for your credentials (username and password); you can store these settings for your current Base session.

[[Image:Conn_ooo_alpha_base.jpg]]

Depending on your connection settings you will now see all databases with all their tables, or just the database you've specified in the connection settings.

== References ==

See the [http://www.openoffice.org/ OpenOffice.org website] for documentation of the office suite and its Extension Manager.

== Known Bugs ==

If you discover a bug in Connector/OpenOffice.org [http://wiki.services.openoffice.org/wiki/Database/Drivers/MySQL_Native/Known_Problems please add it to this list] and send an email to [mailto:users@dba.openoffice.org users@dba.openoffice.org].

== Contact ==

To discuss the new MySQL Connector/OpenOffice.org, please subscribe to the mailing list [http://dba.openoffice.org/servlets/ProjectMailingListList users@dba.openoffice.org]. It is a low-volume list with less than 10 mails per day.

Database/Drivers/MySQL Native/Beta

2009-04-09T13:36:01Z

Nixnutz: /* Known Bugs */

== Introduction ==

MySQL Connector/OpenOffice.org is a MySQL driver for [http://www.openoffice.org/ OpenOffice.org]. It can be used to connect from OpenOffice.org 3.1 to a MySQL server 5.1 or newer.

Before MySQL Connector/OpenOffice.org became available you'd have to use [http://dev.mysql.com/downloads/connector/j/ MySQL Connector/J (JDBC)] or [http://dev.mysql.com/downloads/connector/odbc/ MySQL Connector/ODBC] to connect to a MySQL server.

Therefore the driver is also referred to as a native driver in the context of OpenOffice.org. The term native driver clashes with the MySQL definition of a native driver. MySQL Connector/OpenOffice.org does not implement the MySQL Client Server protocol. Technically speaking the MySQL Connector/OpenOffice.org is implemented as a proxy on top of the [http://dev.mysql.com/doc/refman/5.1/en/connector-cpp.html MySQL Connector/C++].

The driver is delivered as an OpenOffice.org extension.

=== Advantages ===

Using MySQL Connector/OpenOffice.org has the following advantages:

* Easy installation through the OpenOffice.org Extension Manager.
* Seamless integration into OpenOffice.org.
* No need to go through an additional Connector installation routine (ODBC/JDBC)
* No need to configure or register an additional Connector (ODBC)
* No need to install or configure a driver manager (ODBC)

=== Status ===

Please note, the MySQL Connector/OpenOffice.org is released as an alpha version. We do not recommend using the driver in production environments or systems with critical data. Please note, official support is not available.

== Installation ==

=== Install or upgrade to OpenOffice.org 3.1 ===

OpenOffice.org 3.1 is available as a Release Candidate at [http://download.openoffice.org/next/index.html http://download.openoffice.org/next/index.html]. The driver does not work together with any other OpenOffice.org version.

Caution: The installation wizard of OpenOffice.org 3.1 will remove older OpenOffice.org installations from your system by default. If you wo not want this, check out for the corresponding settings of the installation wizard.

=== Download MySQL Connector/OpenOffice.org ===

The alpha version is available as a QA build from [ftp://qa-upload.services.openoffice.org/MySQLNative/ ftp://qa-upload.services.openoffice.org/MySQLNative/] -

The extension is available for the following platforms:
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-windows-x86-32bit.oxt Windows x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-linux-x86-32bit.oxt Linux x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-sparc-32bit.oxt Solaris SPARC, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-x86-32bit.oxt Solaris x86, 32bit]

Save the download to a location of your choice, for example <code>My Documents</code> or <code>~/Documents</code>.

=== Installing the extension ===

Add the <code>.oxt</code> extension through the Extension Manager of OpenOffice.org. In OpenOffice.org, select <code>Tools, Extension Manager...</code> and specify the <code>.oxt</code> file as a new extension. When done, MySQL Connector/OpenOffice.org should show up as a new extension under <code>My Extensions</code>.
: [[Image:Conn_ooo_alpha_extensions.jpg]]

Restart OpenOffice.org to complete the installation.

== Getting Started: Connecting to MySQL ==

MySQL Connector/OpenOffice.org allows you to access the MySQL Server and its schemata from the OpenOffice.org suite.

The following example demonstrates the creation of a new OpenOffice.org Base database which uses a local MySQL Server for storage and the new connector for connecting.

=== Select the database ===

Create a new database (<code>File, New, Database</code>). This starts a wizard that allows you to create a new, open an existing, or connect to existing database. Select the latter option.

From the drop-down list, select <code>MySQL</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard1.jpg]]

=== Select the type of the driver ===

You can use three different MySQL drivers for connecting to MySQL from OpenOffice.org. You can choose a generic ODBC or JDBC connection method or the native driver. Select <code>Connect native</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard2.jpg]]

=== Setting up the database connection ===

Set up the database connection. Put the schema (database) you want to connect to into <code>Name of the database</code>. Enter the URL (host name), Port and Socket of your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard3.jpg]]

=== Fill in user credentials ===

Provide the user credentials for connecting to your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard4.jpg]]

=== Save and proceed ===

Finish the wizard. All defaults are a safe choice. Click <code>Finish >></code>.

[[Image:Conn_ooo_alpha_wizard5.jpg]]

== Getting Started: Usage Examples ==
=== Listing Tables ===
In the Database area of the Base main window, select Tables. If this is the first time you're accessing the database you'll be prompted for your credentials (username and password); you can store these settings for your current Base session.

[[Image:Conn_ooo_alpha_base.jpg]]

Depending on your connection settings you will now see all databases with all their tables, or just the database you've specified in the connection settings.

== References ==

See the [http://www.openoffice.org/ OpenOffice.org website] for documentation of the office suite and its Extension Manager.

== Known Bugs ==

If you discover a bug in Connector/OpenOffice.org [http://wiki.services.openoffice.org/wiki/Database/Drivers/MySQL_Native/Known_Problems please add it to this list] and send an email to [mailto:users@dba.openoffice.org users@dba.openoffice.org]. You need to be logged in with an OpenOffice.org account for both; see [http://dba.openoffice.org/servlets/ProjectMailingListList http://dba.openoffice.org/servlets/ProjectMailingListList] for details.

== Contact ==

To discuss the new MySQL Connector/OpenOffice.org, please subscribe to the mailing list [http://dba.openoffice.org/servlets/ProjectMailingListList users@dba.openoffice.org]. It is a low-volume list with less than 10 mails per day.

Database/Drivers/MySQL Native/Beta

2009-04-09T13:34:45Z

Nixnutz:

== Introduction ==

MySQL Connector/OpenOffice.org is a MySQL driver for [http://www.openoffice.org/ OpenOffice.org]. It can be used to connect from OpenOffice.org 3.1 to a MySQL server 5.1 or newer.

Before MySQL Connector/OpenOffice.org became available you'd have to use [http://dev.mysql.com/downloads/connector/j/ MySQL Connector/J (JDBC)] or [http://dev.mysql.com/downloads/connector/odbc/ MySQL Connector/ODBC] to connect to a MySQL server.

Therefore the driver is also referred to as a native driver in the context of OpenOffice.org. The term native driver clashes with the MySQL definition of a native driver. MySQL Connector/OpenOffice.org does not implement the MySQL Client Server protocol. Technically speaking the MySQL Connector/OpenOffice.org is implemented as a proxy on top of the [http://dev.mysql.com/doc/refman/5.1/en/connector-cpp.html MySQL Connector/C++].

The driver is delivered as an OpenOffice.org extension.

=== Advantages ===

Using MySQL Connector/OpenOffice.org has the following advantages:

* Easy installation through the OpenOffice.org Extension Manager.
* Seamless integration into OpenOffice.org.
* No need to go through an additional Connector installation routine (ODBC/JDBC)
* No need to configure or register an additional Connector (ODBC)
* No need to install or configure a driver manager (ODBC)

=== Status ===

Please note, the MySQL Connector/OpenOffice.org is released as an alpha version. We do not recommend using the driver in production environments or systems with critical data. Please note, official support is not available.

== Installation ==

=== Install or upgrade to OpenOffice.org 3.1 ===

OpenOffice.org 3.1 is available as a Release Candidate at [http://download.openoffice.org/next/index.html http://download.openoffice.org/next/index.html]. The driver does not work together with any other OpenOffice.org version.

Caution: The installation wizard of OpenOffice.org 3.1 will remove older OpenOffice.org installations from your system by default. If you wo not want this, check out for the corresponding settings of the installation wizard.

=== Download MySQL Connector/OpenOffice.org ===

The alpha version is available as a QA build from [ftp://qa-upload.services.openoffice.org/MySQLNative/ ftp://qa-upload.services.openoffice.org/MySQLNative/] -

The extension is available for the following platforms:
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-windows-x86-32bit.oxt Windows x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-linux-x86-32bit.oxt Linux x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-sparc-32bit.oxt Solaris SPARC, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-x86-32bit.oxt Solaris x86, 32bit]

Save the download to a location of your choice, for example <code>My Documents</code> or <code>~/Documents</code>.

=== Installing the extension ===

Add the <code>.oxt</code> extension through the Extension Manager of OpenOffice.org. In OpenOffice.org, select <code>Tools, Extension Manager...</code> and specify the <code>.oxt</code> file as a new extension. When done, MySQL Connector/OpenOffice.org should show up as a new extension under <code>My Extensions</code>.
: [[Image:Conn_ooo_alpha_extensions.jpg]]

Restart OpenOffice.org to complete the installation.

== Getting Started: Connecting to MySQL ==

MySQL Connector/OpenOffice.org allows you to access the MySQL Server and its schemata from the OpenOffice.org suite.

The following example demonstrates the creation of a new OpenOffice.org Base database which uses a local MySQL Server for storage and the new connector for connecting.

=== Select the database ===

Create a new database (<code>File, New, Database</code>). This starts a wizard that allows you to create a new, open an existing, or connect to existing database. Select the latter option.

From the drop-down list, select <code>MySQL</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard1.jpg]]

=== Select the type of the driver ===

You can use three different MySQL drivers for connecting to MySQL from OpenOffice.org. You can choose a generic ODBC or JDBC connection method or the native driver. Select <code>Connect native</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard2.jpg]]

=== Setting up the database connection ===

Set up the database connection. Put the schema (database) you want to connect to into <code>Name of the database</code>. Enter the URL (host name), Port and Socket of your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard3.jpg]]

=== Fill in user credentials ===

Provide the user credentials for connecting to your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard4.jpg]]

=== Save and proceed ===

Finish the wizard. All defaults are a safe choice. Click <code>Finish >></code>.

[[Image:Conn_ooo_alpha_wizard5.jpg]]

== Getting Started: Usage Examples ==
=== Listing Tables ===
In the Database area of the Base main window, select Tables. If this is the first time you're accessing the database you'll be prompted for your credentials (username and password); you can store these settings for your current Base session.

[[Image:Conn_ooo_alpha_base.jpg]]

Depending on your connection settings you will now see all databases with all their tables, or just the database you've specified in the connection settings.

== References ==

See the [http://www.openoffice.org/ OpenOffice.org website] for documentation of the office suite and its Extension Manager.

== Known Bugs ==

If you discover a bug in Connector/OpenOffice.org [http://wiki.services.openoffice.org/wiki/Database/Drivers/MySQL_Native#Known_issues please add it to this list] and send an email to [mailto:users@dba.openoffice.org users@dba.openoffice.org]. You need to be logged in with an OpenOffice.org account for both; see [http://dba.openoffice.org/servlets/ProjectMailingListList http://dba.openoffice.org/servlets/ProjectMailingListList] for details.

== Contact ==

To discuss the new MySQL Connector/OpenOffice.org, please subscribe to the mailing list [http://dba.openoffice.org/servlets/ProjectMailingListList users@dba.openoffice.org]. It is a low-volume list with less than 10 mails per day.

Database/Drivers/MySQL Native/Beta

2009-04-09T13:34:07Z

Nixnutz: New page: Category:MySQLDevelopment Category:Software_Preview == Introduction == MySQL Connector/OpenOffice.org is a MySQL driver for [http://www.openoffice.org/ OpenOffice.org]. It can be ...

[[Category:MySQLDevelopment]]
[[Category:Software_Preview]]
== Introduction ==

MySQL Connector/OpenOffice.org is a MySQL driver for [http://www.openoffice.org/ OpenOffice.org]. It can be used to connect from OpenOffice.org 3.1 to a MySQL server 5.1 or newer.

Before MySQL Connector/OpenOffice.org became available you'd have to use [http://dev.mysql.com/downloads/connector/j/ MySQL Connector/J (JDBC)] or [http://dev.mysql.com/downloads/connector/odbc/ MySQL Connector/ODBC] to connect to a MySQL server.

Therefore the driver is also referred to as a native driver in the context of OpenOffice.org. The term native driver clashes with the MySQL definition of a native driver. MySQL Connector/OpenOffice.org does not implement the MySQL Client Server protocol. Technically speaking the MySQL Connector/OpenOffice.org is implemented as a proxy on top of the [http://dev.mysql.com/doc/refman/5.1/en/connector-cpp.html MySQL Connector/C++].

The driver is delivered as an OpenOffice.org extension.

=== Advantages ===

Using MySQL Connector/OpenOffice.org has the following advantages:

* Easy installation through the OpenOffice.org Extension Manager.
* Seamless integration into OpenOffice.org.
* No need to go through an additional Connector installation routine (ODBC/JDBC)
* No need to configure or register an additional Connector (ODBC)
* No need to install or configure a driver manager (ODBC)

=== Status ===

Please note, the MySQL Connector/OpenOffice.org is released as an alpha version. We do not recommend using the driver in production environments or systems with critical data. Please note, official support is not available.

== Installation ==

=== Install or upgrade to OpenOffice.org 3.1 ===

OpenOffice.org 3.1 is available as a Release Candidate at [http://download.openoffice.org/next/index.html http://download.openoffice.org/next/index.html]. The driver does not work together with any other OpenOffice.org version.

Caution: The installation wizard of OpenOffice.org 3.1 will remove older OpenOffice.org installations from your system by default. If you wo not want this, check out for the corresponding settings of the installation wizard.

=== Download MySQL Connector/OpenOffice.org ===

The alpha version is available as a QA build from [ftp://qa-upload.services.openoffice.org/MySQLNative/ ftp://qa-upload.services.openoffice.org/MySQLNative/] -

The extension is available for the following platforms:
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-windows-x86-32bit.oxt Windows x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-linux-x86-32bit.oxt Linux x86, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-sparc-32bit.oxt Solaris SPARC, 32bit]
* [ftp://qa-upload.services.openoffice.org/MySQLNative/mysql-connector-ooo-alpha-2-solaris-x86-32bit.oxt Solaris x86, 32bit]

Save the download to a location of your choice, for example <code>My Documents</code> or <code>~/Documents</code>.

=== Installing the extension ===

Add the <code>.oxt</code> extension through the Extension Manager of OpenOffice.org. In OpenOffice.org, select <code>Tools, Extension Manager...</code> and specify the <code>.oxt</code> file as a new extension. When done, MySQL Connector/OpenOffice.org should show up as a new extension under <code>My Extensions</code>.
: [[Image:Conn_ooo_alpha_extensions.jpg]]

Restart OpenOffice.org to complete the installation.

== Getting Started: Connecting to MySQL ==

MySQL Connector/OpenOffice.org allows you to access the MySQL Server and its schemata from the OpenOffice.org suite.

The following example demonstrates the creation of a new OpenOffice.org Base database which uses a local MySQL Server for storage and the new connector for connecting.

=== Select the database ===

Create a new database (<code>File, New, Database</code>). This starts a wizard that allows you to create a new, open an existing, or connect to existing database. Select the latter option.

From the drop-down list, select <code>MySQL</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard1.jpg]]

=== Select the type of the driver ===

You can use three different MySQL drivers for connecting to MySQL from OpenOffice.org. You can choose a generic ODBC or JDBC connection method or the native driver. Select <code>Connect native</code>. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard2.jpg]]

=== Setting up the database connection ===

Set up the database connection. Put the schema (database) you want to connect to into <code>Name of the database</code>. Enter the URL (host name), Port and Socket of your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard3.jpg]]

=== Fill in user credentials ===

Provide the user credentials for connecting to your MySQL Server. Click <code>Next >></code>.

[[Image:Conn_ooo_alpha_wizard4.jpg]]

=== Save and proceed ===

Finish the wizard. All defaults are a safe choice. Click <code>Finish >></code>.

[[Image:Conn_ooo_alpha_wizard5.jpg]]

== Getting Started: Usage Examples ==
=== Listing Tables ===
In the Database area of the Base main window, select Tables. If this is the first time you're accessing the database you'll be prompted for your credentials (username and password); you can store these settings for your current Base session.

[[Image:Conn_ooo_alpha_base.jpg]]

Depending on your connection settings you will now see all databases with all their tables, or just the database you've specified in the connection settings.

== References ==

See the [http://www.openoffice.org/ OpenOffice.org website] for documentation of the office suite and its Extension Manager.

== Known Bugs ==

If you discover a bug in Connector/OpenOffice.org [http://wiki.services.openoffice.org/wiki/Database/Drivers/MySQL_Native#Known_issues please add it to this list] and send an email to [mailto:users@dba.openoffice.org users@dba.openoffice.org]. You need to be logged in with an OpenOffice.org account for both; see [http://dba.openoffice.org/servlets/ProjectMailingListList http://dba.openoffice.org/servlets/ProjectMailingListList] for details.

== Contact ==

To discuss the new MySQL Connector/OpenOffice.org, please subscribe to the mailing list [http://dba.openoffice.org/servlets/ProjectMailingListList users@dba.openoffice.org]. It is a low-volume list with less than 10 mails per day.

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-02-02T10:53:00Z

Nixnutz: /* Configure */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

* '''M39''': configure seems broken.

Fix set_soenv.in, if need be. In my case its necessary to modify SYSTEM_HSQLDB to:
ToFile( "SYSTEM_HSQLDB", "NO", "e" );
Also, mysqlcppconn did not compile out-of-the box. It did not find mysql.h and shows the to be expected follow-up errors like mysql_<funcname> not found. I fixed it by modifying LinuxX86Env.sh to "emulate" --with-system-mysql.

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

Also flip the default setting for generating debug output in <code>driver/mysql_debug.cpp</code>. Modify the constructor and set tracing to true:

[...]
/* {{{ MySQL_DebugLogger::MySQL_DebugLogger() -I- */
MySQL_DebugLogger::MySQL_DebugLogger()
: tracing(true)
{
}
/* }}} */
[...]

When building <code>mysqlc</code>, don't forget to enable C/OOo debug output using:

cd mysqlc
build --all debug="something"

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-02-02T10:52:23Z

Nixnutz: /* Configure */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

''M39'': configure seems broken. Fix set_soenv.in, if need be. In my case its necessary to modify SYSTEM_HSQLDB to:
ToFile( "SYSTEM_HSQLDB", "NO", "e" );
Also, mysqlcppconn did not compile out-of-the box. It did not find mysql.h and shows the to be expected follow-up errors like mysql_<funcname> not found. I fixed it by modifying LinuxX86Env.sh to "emulate" --with-system-mysql.

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

Also flip the default setting for generating debug output in <code>driver/mysql_debug.cpp</code>. Modify the constructor and set tracing to true:

[...]
/* {{{ MySQL_DebugLogger::MySQL_DebugLogger() -I- */
MySQL_DebugLogger::MySQL_DebugLogger()
: tracing(true)
{
}
/* }}} */
[...]

When building <code>mysqlc</code>, don't forget to enable C/OOo debug output using:

cd mysqlc
build --all debug="something"

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-29T17:21:41Z

Nixnutz: /* Get sources */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m39
cd DEV300_m39
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

Also flip the default setting for generating debug output in <code>driver/mysql_debug.cpp</code>. Modify the constructor and set tracing to true:

[...]
/* {{{ MySQL_DebugLogger::MySQL_DebugLogger() -I- */
MySQL_DebugLogger::MySQL_DebugLogger()
: tracing(true)
{
}
/* }}} */
[...]

When building <code>mysqlc</code>, don't forget to enable C/OOo debug output using:

cd mysqlc
build --all debug="something"

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/Known Problems

2009-01-27T14:56:25Z

Nixnutz: /* Template for new entries */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27 - needs review

http://pastebin.com/m75809

Severity: undecided

Reason: unknown

=== Exception not converted ===

reported by Ulf on 2009-01-27 - needs review

sql.SQLException not handled in C/OO.org and not converted into SQLException.

.MSG: Calling DatabaseMetaData.getImportedKeys
ERROR: Unexpected Exception exception type not found: sql.SQLException

Same for getIndex().

Severity: undecided

Reason: C/OO.org bug

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27 - needs review

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

=== XCloseable::close throws wrong exception ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

FS: The DisposedException is the usual exception when you try to work with a, well, disposed object. The XCloseable documentation linked above only mentions that an SQLException is thrown in case of a "database access error", anyway. Also, I bet that in the sequence above, the exception is really thrown during executeQuery - which would be correct. In short: I don't see an issue here.

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)
supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject - not sure.

The other three are not used, I think.

=== 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

Severity: required

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

=== 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.

Severity: undecided

FS: works as expected now. As Ulf and /me agreed, C/OOo will not expose the I_S at all.

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish ? java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

FS: Fixed. Since the Connector/OOo does not expose the INFORMATION_SCHEMA anymore, the wizard cannot pick it ...

Database/Drivers/MySQL Native/Known Problems

2009-01-27T14:55:37Z

Nixnutz: /* Template for new entries */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== getProcedureColumns is a stub ===

reported by Ulf on 2009-01-27 - needs review

http://pastebin.com/m75809

Severity: undecided

Reason: unknown

=== Template for new entries ===

reported by Ulf on 2009-01-27 - needs review

sql.SQLException not handled in C/OO.org and not converted into SQLException.

.MSG: Calling DatabaseMetaData.getImportedKeys
ERROR: Unexpected Exception exception type not found: sql.SQLException

Severity: undecided

Reason: C/OO.org bug

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27 - needs review

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

=== XCloseable::close throws wrong exception ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

FS: The DisposedException is the usual exception when you try to work with a, well, disposed object. The XCloseable documentation linked above only mentions that an SQLException is thrown in case of a "database access error", anyway. Also, I bet that in the sequence above, the exception is really thrown during executeQuery - which would be correct. In short: I don't see an issue here.

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)
supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject - not sure.

The other three are not used, I think.

=== 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

Severity: required

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

=== 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.

Severity: undecided

FS: works as expected now. As Ulf and /me agreed, C/OOo will not expose the I_S at all.

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish ? java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

FS: Fixed. Since the Connector/OOo does not expose the INFORMATION_SCHEMA anymore, the wizard cannot pick it ...

Database/Drivers/MySQL Native/Known Problems

2009-01-27T14:28:36Z

Nixnutz: /* Template for new entries */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Template for new entries ===

reported by Ulf on 2009-01-27 - needs review

sql.SQLException not handled in C/OO.org and not converted into SQLException.

.MSG: Calling DatabaseMetaData.getImportedKeys
ERROR: Unexpected Exception exception type not found: sql.SQLException

Severity: undecided

Reason: C/OO.org bug

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27 - needs review

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

=== XCloseable::close throws wrong exception ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

FS: The DisposedException is the usual exception when you try to work with a, well, disposed object. The XCloseable documentation linked above only mentions that an SQLException is thrown in case of a "database access error", anyway. Also, I bet that in the sequence above, the exception is really thrown during executeQuery - which would be correct. In short: I don't see an issue here.

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)
supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject - not sure.

The other three are not used, I think.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

Database/Drivers/MySQL Native/Known Problems

2009-01-27T14:22:48Z

Nixnutz: /* Template for new entries */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== getImportedKeys()/getExportedKeys() ===

reported by Ulf on 2009-01-27 - needs review

Most likely Connector/C++ does not distinguish between "" and NULL parameter values for catalog and schema as requested by the JDBC specs. Do we need the differentiation?

Severity: undecided

Reason: unknown

=== Definition of catalog and schema ===

reported by Ulf on 2009-01-27 - needs review

Connector/J and Connector/C++ use differen meanings for schema and catalog. See getCatalogTerm(). This may impact assorted methods with *catalog*() and *schema*() in their names and also their result sets. In the result sets the meaning of columns like TABLE_CAT and TABLE_SCHEM may differ with Connector/J and Connector/C++.

All C/OO.org methods need to be checked against this and implement whatever logic Base wants.

Severity: undecided

Reason: unknown

=== XCloseable::close throws wrong exception ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

FS: The DisposedException is the usual exception when you try to work with a, well, disposed object. The XCloseable documentation linked above only mentions that an SQLException is thrown in case of a "database access error", anyway. Also, I bet that in the sequence above, the exception is really thrown during executeQuery - which would be correct. In short: I don't see an issue here.

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)
supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject - not sure.

The other three are not used, I think.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

Database/Drivers/MySQL Native/Known Problems

2009-01-27T13:26:21Z

Nixnutz: /* Do we need any of those? */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

(FS): Really, if there is no BOOL type, I tend to think the driver should not offer it. This way, users are not tempted to use it. Finally, this is a dedicated MySQL driver, it must not necessarily emulate features it does not really have.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== XCloseable::close throws wrong exception ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

FS: The DisposedException is the usual exception when you try to work with a, well, disposed object. The XCloseable documentation linked above only mentions that an SQLException is thrown in case of a "database access error", anyway. Also, I bet that in the sequence above, the exception is really thrown during executeQuery - which would be correct. In short: I don't see an issue here.

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getExportedKeys: feature not implemented.

FS: supportsIntegrityEnhancementFacility is used to determine relationship support, but there's meanwhile an exception in the code which enables relationships for MySQL, regardless. (using this method is incorrect, speaking strictly, anyway.)
supportsResultSetConcurrency is not used by default, but its usage can be enabled by the user on a per-database basis. So, it might be better to implement it.

getObject - not sure.

The other three are not used, I think.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

Database/Drivers/MySQL Native/Known Problems

2009-01-26T15:43:41Z

Nixnutz: /* Do we need any of those? */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009 - needs review

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009 - needs review

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: The wizard tries to create a table in the INFORMATION_SCHEMA schema. Bad idea. However, how would a better idea look like? There's no such thing as a "default schema" which could be used, so the wizard picks the first schema which it encounters, which happens to be INFORMATION_SCHEMA.

Note that the problem does not happen when connecting via the JDBC driver, since here a) schemas are in fact reported as catalogs, and there ''is'' such a thing as a default/current catalog (namely [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XConnection.html#getCatalog Connection.getCatalog]), which is used and respected by the wizard.

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Template for new entries ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

Reason: Connector/OO.org, OTypeInfo.hxx(?)

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.
ERROR: SQL Exception: OResultSet::getObject: feature not implemented.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

INVALID :)
When you add a new column to a table, then you need to fill it with unique values, before declaring it as primary key. When you do so, changing the PK to this column works perfectly.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

copy table & paste special (change tablename) with pk ? invalid error message without text appears

Severity: required

Cannot reproduce in latest builds. What happens, though, is that e.g. VARCHAR columns get a wrong length (tripled). This is the well-known problem of wrong column lengths being reported by the driver.

Database/Drivers/MySQL Native/Known Problems

2009-01-26T11:08:22Z

Nixnutz: /* Template for new entries */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009 - needs review

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009 - needs review

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

Reason: pk not detected?

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

copy table & paste special (change tablename) with pk → invalid error message without text appears

Severity: required

Reason: unknown

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Template for new entries ===

reported by Ulf on 2009-01-26 - needs review

The following sequence does not issue a SQLEception but a DisposedException as it seems:

[...]
statement.close()
statement.executeQuery()

It should throw SQLException, accoding to http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XCloseable.html

Severity: undecided

Reason: Connector/OO.org, OTypeInfo.hxx(?)

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Does not happen anymore in latest builds, probably fixed while fixing some of the type info problems.

Database/Drivers/MySQL Native/Known Problems

2009-01-26T10:38:29Z

Nixnutz: /* Do we need any of those? */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== severe character set problems ===

Tables columns containing non-ASCII characters in their name are improperly named in OOo.

Severity: required

Reason: C/OOo is flooded with OUString::createFromAscii usage, not only for column names. It seems that C/Cpp has a 8-bit api, and conversion from/to those API often happens assuming an ASCII encoding, sometimes using an encoding set at the connection (where I currently do not know where it originates from).

I'd say we have a serious problem here.

=== Binary columns are reported as text ===

Columns of type "LONG (VAR)BINARY" are reported as "LONG (VAR)CHAR" in the table designer

Severity: required

Reason: MySQL-internally, binary columns re-use existing types, e.g. MYSQL_TYPE_VAR_STRING for a VARBINARY column. The fact that the column is not text, but binary, is recorded in an additional per-column flag, where the BINARY_FLAG bit is set.
Unfortunately, this information is not transported via C/Cpp. Instead, the DATA_TYPE column of DatabaseMetaData.getColumns returns the untouched MYSQL_TYPE_, which alone is not sufficient to determine the proper column type.

Suggested solution: Either, DatabaseMetaData.getColumns must return additional information, e.g. an additional result set column, taking the column flags. Alternatively, the content of the DATA_TYPE column returned in getColumns must be "normalized", so that VARBINARY and VARCHAR in fact have different data types.

I'd somehow prefer the latter, as this is more future-proof. Also, since C/Cpp claims to have a JDBC-compliant API, it would be the better solution: In JDBC, [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) DATA_TYPE is defined] to contain a value from the java.sql.Types class, which already is a normalization we need ...

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Pointer: MySQL ODBC file utitlity.c get_column_size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009 - needs review

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009 - needs review

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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.

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

Reason: pk not detected?

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

copy table & paste special (change tablename) with pk → invalid error message without text appears

Severity: required

Reason: unknown

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Template for new entries ===

reported by NAME on 2009-mm-dd - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== getWarnings() ===

reported by Ulf on 2009-01-26 - needs review

getWarnings() always returns a warning object, regardless if there is one or not. Should it return NULL? JDBC compliance test expects NULL.

Severity: undecided

Reason: Connector/OO.org

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT/VARCHAR.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

=== Perfoemance problem when accessing big tables ===

Open a table with more then 1000 rows. Jump to last one. => 2 min.

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

FIXED: Error message: Database not support relations.
ERROR: Still not possible to create new relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

=== DECIMAL shown as TEXT ===

Base shows numerical DECIMAL columns as TEXT (in the table editor?).

Severity: required

Investigation: column is reported as <code>MYSQL_TYPE_NEWDECIMAL</code>, which wasn't covered in C/OOo (which only had a case for <code>MYSQL_TYPE_DECIMAL</code>)
=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Does not happen anymore in latest builds, probably fixed while fixing some of the type info problems.

Database/Drivers/MySQL Native/Known Problems

2009-01-23T09:47:35Z

Nixnutz: /* Do we need any of those? */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on xx/01/2009 - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009 - needs review

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009 - needs review

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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 (in the table editor?).

Severity: required

I'm 95% sure C/C++ and C/OOo report a proper column type.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: unknown

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

Reason: pk not detected?

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

copy table & paste special (change tablename) with pk → invalid error message without text appears

Severity: required

Reason: unknown

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Do we need any of those? ===

ERROR: SQL Exception ODatabaseMetaData::getCrossReference: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getProcedures: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::getUDTs: feature not implemented.
ERROR: SQL exception ODatabaseMetaData::supportsIntegrityEnhancementFacility: feature not implemented.
ERROR: SQL Exception ODatabaseMetaData::supportsResultSetConcurrency: feature not implemented.

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

Error message: Database not support relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

Database/Drivers/MySQL Native/Known Problems

2009-01-23T09:34:19Z

Nixnutz: /* INSERT does not work */

{{DISPLAYTITLE:MySQL Native Driver: Known Problems}}

This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.

== End User Observations ==

This section collects issues as observed by end users

=== Template for new entries ===

reported by NAME on xx/01/2009 - needs review

Description goes here.

Severity: undecided

Reason: unknown

=== Copying tables may not work properly ===

reported by NAME on xx/01/2009 - needs review

'''Needs further and systematic testing!'''

Original table:

CREATE TABLE `source` (
`id` int(11) NOT NULL,
`col1` int(11) NOT NULL,
`col2` char(1) default NULL,
`col3` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_col1` (`col1`),
KEY `idx_col2` (`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Copy:

CREATE TABLE `source2` (
`id` int(10) NOT NULL,
`col1` int(10) default NULL,
`col2` char(3) default NULL,
`col3` varchar(150) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

* Wrong column definitions (known issue)
* NOT NULL not properly handled
* Index information not copyied (same with JDBC, might be a Base issue)

Severity: undecided

Reason: unknown

=== Wrong column width reported for text/binary columns ===

reported by Ulf on 09/01/2009 - needs review

We discussed this before and it might be fixed in the current source, but I work on an older snapshot. We return number of bytes, OO.org wants number of characters. A typical follow-up error is that copying tables may fail and/or give wrong results.

From an earlier mail exchange:

Hintergrund: für eine VARBINARY(10)-Spalte in MySQL liefern wir aktuell
40, für eine INTEGER-Spalte in MySQL liefern wir aktuell 11. Wir liefern
momentan 40 für VARBINARY(10), weil das Feld maximal 10 Zeichen aufnehmen kann, die maximal 4 Bytes für das Encoding benötigen. Für ein VARCHAR(255) wird sogar VARCHAR(255) der Wert von 3060 geliefert, weil hier der MySQL Server nochmal in einem seiner Datenfelder einen Mul tiplikator von 3 einbaut (255 * 3 * 4 = 3060).

And:

Später am Abend fiel es mir wieder ein... wir ziehen getColumnDisplaySize() intern im Connector/C++ ran für ConnectionMetaData::getColumns() -> COLUMN_SIZE.
rs_data.push_back(my_i_to_a(buf, sizeof(buf)-1, (long) rs3_meta->getColumnDisplaySize(i))); // Column size

Severity: required

Reason: unknown

=== Renaming a view not possible ===

reported by Ulf on 09/01/2009 - needs review

Tested with the native driver: Its not possible to rename a view, the UI does not offer the context menu item when selecting the view in the table list.

Severity: desired

Reason: missing SDBCX support of the driver. In general, tables can only be renamed when there is a css.sdbcx.Table object representing a single table, which supports the XRename interface.

=== (JDBC) Renaming a view "makes" it a table ===

reported by Ulf on 09/01/2009 - needs review

Tested with the JDBC driver. Create a view and rename it in Base. Base changes the icon in the table list and shows the renamed object as a table :-)

Severity: low

Reason: unknown

=== Removing records from views fails ===

reported by Ulf on 08/01/2009

Removing records from SQL views neither works with the JDBC driver nor with the native driver. Base sends a misformed query like: "DELETE FROM `test`.`v` W"

Severity: low

Reason: Removing records from views is in general not possible in Base. The fact that "Edit/Delete record" is enabled for a view (as in any table which the user does not have the DELETE privilege for) is a bug, which I fixed in the CWS.

=== 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 shown.

Severity: desired

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 (in the table editor?).

Severity: required

I'm 95% sure C/C++ and C/OOo report a proper column type.

=== SMALLINT shown as REAL ===

When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)

Severity: required

=== 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, and also display all those tables.

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

Severity: desired

=== 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 certain schema by specifying it in the connection settings.

Severity: desired

=== 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).

Severity: 1.1

=== 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.

Severity: low

that's not nice, but consistent with other DB/Drivers. For this purpose, there's View/Refresh Tables ...

=== Table column comments not synced between MySQL and Base ===

Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.

Severity: later

That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...

=== Violation of FK constraint gives 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.

This is a common pattern. Cause any SQL error and you can see up to three errors when you quit the initial requester using the button "more". Quite annoying, for example, when writing SQL statements for a Base "Query" object.

Severity: undecided

The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ... (Ulf) But why does it work fine with the JDBC driver?

=== Default values not properly processed ===

The Base table editor neither properly sets default values nor does it re-engineer default values properly.

Severity: 1.1

Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to ''controls'' used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.

Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.

=== 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.

Severity: undecided

I bet that's because of the number formatter ... processing numbers for display is done using a office-wide number formatter component. Unfortunately, it works with double-precision values only, which imposes a precision loss for certain values. This applies to "too-large" values, as well as fractional values with "too many" digits. This is a general problem in Base, and not limited to the MySQL Native Driver.

A possible solution would be to '''not'' employ the number formatter for certain column types. (Effectively, this means ''not'' using a <code>FormattedField</code> for the respective table column in the data view, but a NumericField, which internally works with long integer values of arbitrary (?) length.) This would solve the BIGINT issue, though not the too-many-digits issue for fractional values.

=== 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.

Severity: required

Fixing this should be easy, at least so it is as usable as with other DBs/drivers, in particular with the existing MySQL-(O/J)DBC bridge. Before sending statements to the server, the driver must replace (unless the statement's <code>EscapeProcessing</code> is <code>FALSE</code>, of course) named parameters with anonymous ones. The disadvantage is that this only works when Base itself can parse the statement, and that it potentially changes the statement. However, both statements are true for all other DBs which do not support named parameters, too.

=== Tools -> User Administration does not work ===

When you choose <code>Tools/User administration...</code>, you're presented with an error.

Severity: required (remove the menu item)

Severity: required (implement proper user administration)

=== create table with wizard fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

run table wizard: take default & all field & push finish → java assertion list appears

Severity: required

Reason: unknown

=== change pk fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

open table with pk and change pk to any other field -> error: duplicate entry for key

Severity: required

Reason: pk not detected?

=== change table fieldtype in edit view not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

open table in edit mode -> fieldtypes greyed out (not possible to change)

Severity: required

Reason: The driver does not support <code>XAlterTable</code> (and more SDBCX-level interfaces)

=== fieldtype is changed after saving ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

in table edit view: create a field from f.e. type bool & save → tinyint

Severity: required

Reason: maybe the same problem like 1.10 & 1.11

(Ulf) Duplicate and not an error in C/C++. There is no boolean type in MySQL. However, its handled in the JDBC driver case, the best we can do is emulate it in the same way.

=== copy table & paste special fails ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

copy table & paste special (change tablename) with pk → invalid error message without text appears

Severity: required

Reason: unknown

=== query wizard shows 'query' as 'table' ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009 - needs review

create any query, open query wizard → tables listbox propose query (also with the other wizards)

Severity: required

Reason: unknown

== Developer Observations ==

This section collects observations interesting for developers only. It's likely the describe the root cause for another problem listed in the ''End User Observations'' section. In this sense, they might be duplicates, but we currently just use this as reminder list whenever we notice a problem ...

=== Do we need any of those? ===

=== 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

Severity: required

=== 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.

Severity: undecided

=== DatabseMetaData::getColumns() COLUMN_SIZE ===

DatabseMetaData::getColumns() takes COLUMN_SIZE from getDisplaySize().

Affected: DECIMAL/FLOAT.

Severity: required

Note: DisplaySize is not the same as ColumnSize. The former is a hint for UI processors which are to display the data in a tabular way. Currently, Base does not make use of this attribute.
The ColumnSize's semantics is described in the [http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String) Java API], and Base uses it in the very same semantics.
As a consequence, COLUMN_SIZE is what needs to be tweaked.

=== DatabseMetaData::getColumns() DECIMAL_DIGITS ===

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

Severity: required

== Potential Issues ==

This section serves as collection of issues which might become a problem to end users, though we did not yet (bother to) create scenarios where users are hit by those (potential) problems.

=== 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.

Severity: undecided

=== 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.

== fixed ==

=== Tools -> Relations... not working ===

Error message: Database not support relations.

We should hint MySQL users in the driver documentation that Base takes no(?) measures to clean up no longer needed indexes. MySQL's InnoDB needs some special treatment.

Severity: required

With 3.x, Base is able to administrate MySQL's relationships (via the ODBC/JDBC bridge), so the native driver should be able to do this, too. At least with approximately the same set of bugs as the "old" driver :)

=== insert data in table not possible ===

reported by [http://wiki.services.openoffice.org/wiki/User:Clu CLU] on 12/01/2009

create any table with pk → not possible to insert data into table

Severity: required

Investigation: The driver currently returns an empty result set when being asked for the table privileges: <code>getTablePrivileges( null, "schema", "table" )</code>. Debugging deeper seems to indicate that parsing the result of a "SHOW GRANTS" query is flawed.

=== Tools->SQL does not show error message ===

reported by Ulf on 08/01/2009

Open the SQL execution wizard by invoking Tools->SQL. Run an invalid SQL query, for example, "create table foo". Base prints a new line "n:" in the status part of the window but it shows no error message.

Severity: required

=== New tables shown after "refresh tables" but (delete) rights/grants wrong? ===

reported by Ulf on 08/01/2009

Create some tables in MySQL. Start Base and browse the table list. Create a new table in MySQL (not in Base!), make sure it has a PK, add some records. Select View->Refresh tables. Base will show the new table. Try to remove a row from the newly created table. Base rejects the delete operation stating that the user as insufficient rights.

Investigation: This is a general problem currently, <code>DatabaseMetaData::getTablePrivileges</code> returns wrong data (all the time? sometimes? andrey claimed to have fixed this, but the fix does not work for me). If I fake the getTablePrivileges implementation to return the full set of privileges regardless the table being asked for, then the problem does not happen.

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-21T12:11:52Z

Nixnutz: /* Debug hints */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

Also flip the default setting for generating debug output in <code>driver/mysql_debug.cpp</code>. Modify the constructor and set tracing to true:

[...]
/* {{{ MySQL_DebugLogger::MySQL_DebugLogger() -I- */
MySQL_DebugLogger::MySQL_DebugLogger()
: tracing(true)
{
}
/* }}} */
[...]

When building <code>mysqlc</code>, don't forget to enable C/OOo debug output using:

cd mysqlc
build --all debug="something"

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-21T12:07:46Z

Nixnutz: /* Debug hints */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

Also flip the default setting for generating debug output in driver/mysql_debug.cpp. Modify the constructor and set tracing to true:

[...]
/* {{{ MySQL_DebugLogger::MySQL_DebugLogger() -I- */
MySQL_DebugLogger::MySQL_DebugLogger()
: tracing(true)
{
}
/* }}} */
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-19T15:45:24Z

Nixnutz: /* "System build" */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

'''TODO''': There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-19T15:45:01Z

Nixnutz: /* Compiling the driver (manually) */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

==== "System build" ====

This describes a set up where you compile the extension against the MySQL Connector/C++ installed on the system. The usage of --with-system-mysqlcppconn may or may not work. We are focussing on the "standalone" build for the moment.

TODO: There seems to be a dispute in the OpenOffice.org developer group if --with-system* refers to build or to build and compile time. The question is if --with-system* is set, should an extension contain all libraries it depends on or not. For example, if --with-system-mysqlcppconn is set, should the MySQL Connector/C++ libraries be part of the extension or not. However, this is a question that goes beyond the scope of the MySQL driver. Its a general question to be discussed on a general level.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-19T15:25:10Z

Nixnutz: /* "Standalone build" */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

Check the build message for the location of the extension, for example:

DEV300_m37> dmake killobj && build --all && deliver
[...]
cp -f /tmp/mkdF4yFR.mysql-native_.oxt ./unxlngi6.pro/bin/mysql-native.oxt
rm -f /tmp/mkdF4yFR.mysql-native_.oxt
-------------
rmdir /tmp/11964
deliver -- version: 1.130
Module 'mysqlc' delivered successfully. 0 files copied, 1 files unchanged

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-19T15:22:26Z

Nixnutz: /* "Standalone build" */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc
DEV300_m37/mysqlc> dmake killobj && build --all && deliver

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/OOoBuildEnvironment

2009-01-19T15:21:07Z

Nixnutz: /* Compiling the driver (manually) */

= How to set up an OpenOffice.org Build environment for C/OOo development =

= SuSE Linux =

== SuSE 11 ==

SuSE 11 does not use Sun Java by default. The default installation will come with GNU Java and javac = GCC. Don't use the GNU stuff, use Sun's Java SDK 1.5. Deinstall GNU Java, search for java and gcj in Yast. OpenOffice 3.0 M28 might fail to detect GNU Java and might not come up with any proper error message during configure.

== Beware ==

If your connection is not OC-192 ;), then you might want to log into a server with a fast connection and do the following there. The just pack the sources and download them locally using scp.

== Prerequisites ==

This list is based on what is needed to be additionally installed on a virgin Ubuntu 8.10 Interpid/Debian 4r6 Etch system. If might be different for you, meaning you might need to install more packages. However, be sure you have these to skip some iterations of [configure [, install ]]+

* libarchive-zip-perl (Perl Archive/Zip)
* libcupsys2-dev
* libpam0g-dev
* sdk-java 1.5
* gperf
* libfreetype6-dev
* libxaw7-dev
* libfontconfig1-dev
* libxrandr-dev
* libgconf2-dev
* libgnomevfs2-dev
* libgdk-pixbuf-dev
* ant
* bison
* flex
* zip
* unzip

== Get sources ==

* Without a key
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn://svn.services.openoffice.org/ooo/cws/mysqlnative

* Get sources - with a key
svn checkout svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m37
cd DEV300_m37
svn switch svn+ssh://svn@svn.services.openoffice.org/ooo/cws/mysqlnative

== Configure ==

* Get unowinreg.dll from http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll and use it
cp /path/to/download/of/unowinreg.dll external/unowinreg/

* Get 3 zips from http://tools.openoffice.org/moz_prebuild/680/ and use them
cp /path/to/download/of/LINUXGCCIinc.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIlib.zip moz/zipped/
cp /path/to/download/of/LINUXGCCIruntime.zip moz/zipped/

OpenOffice will search for <OS><COM><CPU>{inc,lib,runtime}.zip in moz/zipped/ . You might have to rename the download files. Watch out for error messages returned by configure (see below).

* Configure (distribution build - "pro" build)
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash

* Configure (debug build, with asserts - "non-pro")
cd config_office
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --enable-dbgutil

I was able to configure on openSuSE11.0 with the following command, after installing all needed libraries :
./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-system-freetype \
--with-system-stdlibs --with-system-cairo --with-system-zlib --with-system-openssl --with-system-jpeg \
--with-system-expat --with-system-freetype --with-system-libwpd --with-system-libxml --with-system-python \
--with-system-icu --with-system-db --with-system-lucene --with-system-hsqldb --with-system-beanshell \
--with-system-libxslt --with-system-odbc-headers --with-system-sane-header --with-system-curl \
--with-system-boost --with-system-vigra --with-system-neon

I tried --with-system-libs but got into problems finding some packages. If you get libegg problems (I do) add --disable-systray

== Build ==

* Follow the messages, probably you have to do the following, if you have used bash as shell for the build in the configure line. For tcsch use LinuxX86Env.Set:
cd ..
source LinuxX86Env.Set.sh
./bootstrap

* If you have dual or quad-core, or SMP, run the following and adjust for your configuration
export MAXPROCESS=3

* ccache is very recommended, go install it. Then configure it to have enough space. By default it stores data in your home directory. This is configurable like (I have CC and CXX changed in .bashrc but some people prefer to do a symlink):

export CCACHE_DIR="/path/to/ccache/dir/for/oo.org/build"
ccache -M 2G -F 100000
export CC="ccache gcc"
export CXX="ccache g++"

* dmake should have been boostrapped. Now just run the following and go get a 6h sleep :)
dmake

== SSH Keys ==
On Unix or Windows/cygwin a SSH identity (private/public key pair) is generated with:

ssh-keygen -t dsa
You'll be asked for pass phrase which protects your private key. Per default the public key is named $HOME/.ssh/id_dsa.pub. Note that SSH keys created between September 2006 and May 2008 on Debian or Debian derived systems like Ubuntu may be insecure. Please use recent SSH tools. If you want a dedicated identity for just OOo SVN usage, generate a specially named key pair:
ssh-keygen -t dsa -f ~/.ssh/id_dsa_ooo_svn
and instruct Subversion to use this identity (key pair) with the following configuration entry in $HOME/.subversion/config:
[tunnels]
ssh = ssh -i /home/andrey/.ssh/id_dsa_ooo_svn

=== RPM Installation ===

Something like this...

rpm -Uhv ./instsetoo_native/unxlngi6.pro/URE/rpm/install/en-US/RPMS/openoffice.org-ure-1.4.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core01-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core02-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core03-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core04-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core05-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core06-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-core07-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooofonts-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-images-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-testtool-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-impress-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-pyuno-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-javafilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-xsltfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-graphicfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-ooolinguistic-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-help-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-writer-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-impress-3.1.0-9367.i586.rpm instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-binfilter-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-calc-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-math-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-draw-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-res-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/ooobasis3.1-en-US-base-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-en-US-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice_SDK/rpm/install/en-US/RPMS/ooobasis3.1-sdk-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/openoffice.org3-dict-en-3.1.0-9367.i586.rpm ./instsetoo_native/unxlngi6.pro/OpenOffice/rpm/install/en-US/RPMS/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/openoffice.org3.0-suse-menus-3.0-9367.noarch.rpm ./sysui/unxlngi6.pro/bin/desktop-integration/broffice.org3.0-suse-menus-3.0-9367.noarch.rpm

=== DEB Installation ===

Something like this...

cd instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb
cd desktop_integration
sudo dpkg -i *.deb

Then the programs are in /opt/openoffice3/program/

= Compiling the driver =

Ok, you got OpenOffice.org to compile, and it has finished compiling after 3-6 hours.

== Patching the CWS ('''you need this if you don't use m37 or up''') ==

The latest driver code is still not in the CWS. You need to fetch it from bazaar. We will streamline compiling and commit the source into the CWS as soon as possible. Make sure that you have the OOo build environment set up when compiling the driver (source LinuxX86Env.Set.sh etc.)

Add the MySQL driver to the source tree:

DEV300_m35> cd connectivity/source/drivers/
DEV300_m35/connectivity/source/drivers> bzr clone bzr+ssh://<user>@bk-internal.mysql.com/bzrroot/public/connector-ooo-bzr/trunk/

Add the driver to the OOo build process by patching connectivity/prj/build.lst:

DEV300_m35> nano connectivity/prj/build.lst

Add a line to the build list for compiling the mysql driver, for example:

cn connectivity\source\drivers\trunk nmake - all cn_mysqlc cn_dbtools cn_inc NULL

=== Compiling the driver (manually) ===

The configure flags --enable-mysql-driver, --with-system-mysql and --with-system-mysqlcppconn are work in progress. They may or may not work when you read this. The first goal is to get the driver compile at all. Later on, we can make it user-friendly and Linux distribution-friendly. Manual fine-tuning of makefiles is to be expected - ''for now''.

==== "Standalone build" ====

Builds the driver with as little external requirements as possible. In this configuration you will create a static build. The driver will be build against the MySQL Connector/C++ sources contained in the CWS.

However, you must have the MySQL Server installed on your system. At the time of writing, you should use --with-system-mysql on Linux. Use grep to ensure that its set and, if not, set SYSTEM_MYSQL="YES" in your environment:

DEV300_m37> grep SYSTEM_MYSQL LinuxX86Env.Set.sh
SYSTEM_MYSQL="YES"
SYSTEM_MYSQL_CPPCONN="NO"

On Windows you should use SYSTEM_MYSQL="NO" and consequently omit --with-system-mysql when configuring OO.org. You will need to edit mysqlc/makefile.mk and patch it to point to your MySQL installation directory and the location of the MySQL Client Server Library:

DEV300_m37> grep -n "MYSQL_.*DIR" mysqlc/makefile.mk
72: MYSQL_LIBDIR=D:$/mysql-5.1.24-rc-win32$/lib$/debug
73: MYSQL_INCDIR=D:$/mysql-5.1.24-rc-win32$/include
78: MYSQL_LIBDIR=/export/home/oj93728/mysql/lib
79: MYSQL_INCDIR=/export/home/oj93728/mysql/include

The basic steps are:
* Install the MySQL Server on your build host
* Build and deliver mysqlcppconn/ (the MySQL Connector/C++ used by the OO.org driver)
* Build and deliver connectivity/
* Build and deliver mysqlc/ (the MySQL native driver for OO.org)

On the command line it looks like:

DEV300_m37> cd mysqlcppconn/
DEV300_m37/mysqlcppconn> dmake killobj && build --all && deliver
DEV300_m37> cd ../connectivity
DEV300_m37/connectivity> rm -rf unxlng* && build --all && deliver
DEV300_m37> cd ../mysqlc

Hint: usually you can omit "dmake killobj" and "rm -rf unxlng*" to clear compile caches.

=== Driver/extension installation ===

You can either install the extension in the GUI or use "unopkg". If you want to use "unopkg" make sure that you run it in a shell that does NOT have the build environment set up (source LinuxX86Env.Set.sh etc. must NOT have been run before).

> /opt/openoffice.org3/program/unopkg list
all deployed user packages:
Identifier: org.openoffice.legacy.mysql-native.oxt
Version: 0.0.1
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/JjWiOU_/mysql-native.oxt/mysqlc.so
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=native;platform=Linux_x86
Description:
}

> /opt/openoffice.org3/program/unopkg remove org.openoffice.legacy.mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

> /opt/openoffice.org3/program/unopkg add ~/DEV300_m35/connectivity/unxlngi6.pro/bin/mysql-native.oxt
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static
MysqlCDriver::getSupportedServiceNames_Static
MysqlCDriver::getImplementationName_Static

=== Debug hints ===

If you follow the above instructions you create a debug build.

You can enable the libmysql and Connector/C++ internal traces. To enable the Connector/C++ trace (should be on by default ATM), patch driver/mysql_debug.h:

[...]
#ifndef _MYSQL_DEBUG_H_
#define _MYSQL_DEBUG_H_

#if 1
#define CPP_ENTER(msg) MySQL_DebugLogger * __l = this->logger? this->logger->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, logger)
#define CPP_ENTER_WL(l, msg) MySQL_DebugLogger * __l = (l)? (l)->get():NULL;(void)__l;\
MySQL_DebugEnterEvent __this_func(__LINE__, __FILE__, msg, (l))
#define CPP_INFO(msg) {if (__l) __l->log("INF", msg); }
#define CPP_INFO_FMT(...) {if (__l) __l->log_va("INF", __VA_ARGS__); }
#define CPP_ERR(msg) {if (__l) __l->log("ERR", msg); }
#define CPP_ERR_FMT(...) {if (__l) __l->log_va("ERR", __VA_ARGS__); }
#else
[...]

= OpenSolaris notes (OUTDATED) =

'''NOTE: I'm still fighting with OpenSolaris issues'''
NOTE: The OOo team works only on Solaris 8(!).

* Install OpenSolaris from 2008.05 CD image (Sun Microsystems Inc. SunOS 5.11 snv_86 January 2008)
* Update OpenSolaris to current version

The update will download approx. 1.5 - 2 GB. Accordingly it will take some time.

pfexec pkg refresh
export PKG_CLIENT_TIMEOUT=300
pfexec pkg install SUNWipkg
pfexec pkg image-update
su
pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
pfexec reboot

At the time of writing you will end up with SunOS opensolaris 5.11 snv_95 .

* Install additional packages required for compiling OOo 3.0

Start with SunStudio (ss-dev) and assorted development libraries/tools. That's another ~700MB to download.

pfexec pkg install SUNWcvs ss-dev SUNWxorg-headers SUNWgnu-gperf SUNWcurl
pfexec pkg install SUNWgnome-common-devel SUNWxwinc SUNWant SUNWlxml SUNWicu

There is a bug in OpenSolaris and SUNWxorg-headers will not install all required X headers/libraries! You need to install old versions of the FSWxorg-headers package. You must use old versions because newer versions are empty - their binaries conflict with SUNWxorg-headers and OpenSolaris decided to silently distribute empty packages. Use pfexec pkg contents FSWxorg-headers to check wheter this has been fixed... if not:

pfexec pkg install FSWxorg-data@0.5.11-0.79 FSWxorg-headers@0.5.11-0.79

* Fix/Hack libXaw installation

As explained the FSWxorg* and SUNWxorg* packages might conflict. You need some header from FSWxorg* including libXaw. However, you need to compile libXaw manually although some of its headers are part of FSWxorg-headers.

export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
wget http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2
bunzip2 libXaw-1.0.4.tar.bz2
tar xvf libXaw-1.0.4.tar
cd libXaw-1.0.4
CC=cc ./configure --prefix=/usr/X11
make;
su
make install

* Install missing Perl packages

OOo needs some Perl packages. You will need to install at least Archive::Zip. Some Archive::Zip dependencies might require a C compiler. If you run into issues make sure that you give Perl whatever C compiler it wants. If possible go for the Sun Compiler (CC=/opt/SunStudioExpress/bin/cc CXX=/opt/SunStudioExpress/bin/CC).

su
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
perl -MCPAN -e shell
shell> install Archive::Zip

* Install OpenOffice.org sources as described for Linux
* Patch configure

The OOo team does use one Solaris 8 reference system to cover all *Solaris* versions. Naturally this means that configure will not work out-of-the-box on OpenSolaris. You will need to fix several issues manually. Check out for:

** SunStudio C Compiler wrong version - found 5.10 needs 5.9

That's nothing but a stinky configure. Add a test for 5.10 to configure and make configure accept 5.10.

** Wrong ANT version 1.6.5 needs at least 1.6.0

You need to set the JAVA_HOME through --with-jdk-home=/usr/jdk/latest

** Cannot find ANT libraries

Check the location of ant.jar using

pfexec pkg search -r ant.jar

As you will see, the path it has changed over time. OOo does not search any of the OpenSolaris places by default. Find out the current location using

pkg contents -t file SUNWant | grep ant.jar

At the time of writing its usr/share/lib/ant/ant.jar . Either patch configure or set ANT_HOME - export ANT_HOME=/usr/share/lib/ant

* Run configure

You are getting closer to running configure... Make sure you say "bash". For whatever reason it sets the appropriate path to the GNU patch utility.

bash
cd oo.org-m28/config-office
export PATH=$PATH:/opt/SunStudioExpress/bin/:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin/
CC=cc CXX=CC ./configure --disable-build-mozilla --disable-mediawiki --with-use-shell=bash --with-jdk-home=/usr/jdk/latest/ --with-system-curl

See above on known configure issues.

* Source && Bootstrap

nixnutz@opensolaris:~/oo.org-m28/config_office$ cd ..
nixnutz@opensolaris:~/oo.org-m28$ source SolarisX86Env.Set.sh
nixnutz@opensolaris:~/oo.org-m28$ ./bootstrap

* Start building OOo using dmake

nixnutz@opensolaris:~/oo.org-m28$ dmake

Most likely this will fail! Why? OOo will invoke the make utility with GNU make specific flags. Even more: OOo might try to build icu and the bundled icu will not build with Sun make at all. You might need to use GNU make. I have no idea how to tell OOo that it shall use /usr/gnu/bin/make instead of /usr/ccs/bin/make. I modified the soft link /usr/ccs/bin/make - blame me...

Database/Drivers/MySQL Native/Overview

2009-01-19T11:32:31Z

Nixnutz: /* Status and Releases */

== MySQL driver for OpenOffice.org ==

The MySQL driver for OpenOffice.org (also called Connector/OO.org) is a "native" MySQL driver for OpenOffice.org. Before the development of the Conenctor/OO.org, OO.org has used JDBC/ODBC to connect to the MySQL Server. JDBC/ODBC adds an extra level of indirection to the connection and is generally speaking more difficult to install but Connector/OO.org.

Please note that this page is not part of the end-user documentation, check [[http://forge.mysql.com/wiki/Connector_OpenOffice MySQL Forge Connector/OpenOffice] for end-user documentation.. This page is part of the project documentation and used by the development team to coordinate their work.

== Goal ==

Develop a "native" MySQL driver for OpenOffice.org which is at least as feature-complete as other drivers. Complete the task before the release of OO.org 3.0.

== Status and Releases ==

'''[[Media:Mysql_native_driver_roadmap_rev1.pdf|Development Roadmap of the MySQL native driver for OpenOffice.org / MySQL Connector/OpenOffice.org]]'''

* 04/2009 - GA
* 03/2009 - Beta
* '''01/2009 - Working towards Alpha'''
* 12/2008 - Internal redesign to run on MySQL Connector/C++
* 05/2008 - 11/2008 - Almost no active development
* 04/2008 - Preview version released for OO.org 2.4
* 02/2008 - Kick-Off Meeting Hamburg
* Before - Native driver development by Georg Richter

== Development team ==

'''Primary contact person'' shown in bold letters.

=== OpenOffice.org/StarOffice Base ===

* '''Frank Schoenheit''', Technical Lead OpenOffice.org/StarOffice Base, firstname dot lastname at sun dot com, (Development)
* Ocke Janssen, firstname dot lastname at sun dot com, (Development)

=== MySQL ===

* Georg Richter, Development Manager - Connectors & Client Connectivity, firstname at mysql dot com, (Development)
* '''Ulf Wendel''', Senior Software Engineer, uwendel at mysql dot com, (QA, Documentation)
* Andrey Hristov, Software Engineer, firstname at mysql dot com, (Development)
* Lawrenty Novitsky, Software Developer, lawrin at mysql dot com, (QA, Development)

== Meetings ==

* 22.05.2008 - Technical Meeting of the entire Development team
* 29.04.2008 - [[Database/Drivers/MySQL_Native/Meeting_Minutes | Technical Meeting, Hamburg]]
* 12.02.2008 - Non public Kick-Off Meeting, Hamburg

== Technical Documentation ==

* [[Database/Drivers/MySQL Native/TestingIdeas|Ideas for testing]]

=== Infrastructure ===

* Mailinglists and IRC
** dev@openoffice.org
** irc.freenode.org - #dev.openoffice.org

* OpenOffice 3 CVS
** checkout: cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout -r DEV300_m10 OpenOffice3
** update to CWS code status: cvs update -r cws_dev300_mysqlnative

* [[CWS|CWS (child workspace)]] of Connector/OO.org
** [http://www.openoffice.org/scdocs/ddSSHGuide CVS/SSH instructions]
** Web interface - EIS (Environment Information System) link to CWS: [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmysqlnative mysqlnative]
* Build environment on lsmy3 (MySQL internal)
** [http://tools.openoffice.org/ Introduction on Building OOo]
** For general questions ask on the OOo community mailing lists

* MySQL Connector/OpenOffice.org
** [[Database/Drivers/MySQL Native/Connector/C-OOo-Connect-URL | Connection-URL]]

=== OpenOffice.org ===

* [[Database/Drivers/MySQL_Native/Architecture|OpenOffice.org/StarOffice Base - database driver architecture overview]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%29_Interface|SDBC(X) Interface which has to be supported]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%292MySQL|Mapping of SDBC(X) and MySQL interface]]

Database/Drivers/MySQL Native/Overview

2009-01-19T11:32:00Z

Nixnutz: /* Status and Releases */

== MySQL driver for OpenOffice.org ==

The MySQL driver for OpenOffice.org (also called Connector/OO.org) is a "native" MySQL driver for OpenOffice.org. Before the development of the Conenctor/OO.org, OO.org has used JDBC/ODBC to connect to the MySQL Server. JDBC/ODBC adds an extra level of indirection to the connection and is generally speaking more difficult to install but Connector/OO.org.

Please note that this page is not part of the end-user documentation, check [[http://forge.mysql.com/wiki/Connector_OpenOffice MySQL Forge Connector/OpenOffice] for end-user documentation.. This page is part of the project documentation and used by the development team to coordinate their work.

== Goal ==

Develop a "native" MySQL driver for OpenOffice.org which is at least as feature-complete as other drivers. Complete the task before the release of OO.org 3.0.

== Status and Releases ==

[[Media:Mysql_native_driver_roadmap_rev1.pdf|Development Roadmap of the MySQL native driver for OpenOffice.org / MySQL Connector/OpenOffice.org]]

* '''01/2009 - Working towards Alpha'''
* 12/2008 - Internal redesign to run on MySQL Connector/C++
* 05/2008 - 11/2008 - Almost no active development
* 04/2008 - Preview version released for OO.org 2.4
* 02/2008 - Kick-Off Meeting Hamburg
* Before - Native driver development by Georg Richter

== Development team ==

'''Primary contact person'' shown in bold letters.

=== OpenOffice.org/StarOffice Base ===

* '''Frank Schoenheit''', Technical Lead OpenOffice.org/StarOffice Base, firstname dot lastname at sun dot com, (Development)
* Ocke Janssen, firstname dot lastname at sun dot com, (Development)

=== MySQL ===

* Georg Richter, Development Manager - Connectors & Client Connectivity, firstname at mysql dot com, (Development)
* '''Ulf Wendel''', Senior Software Engineer, uwendel at mysql dot com, (QA, Documentation)
* Andrey Hristov, Software Engineer, firstname at mysql dot com, (Development)
* Lawrenty Novitsky, Software Developer, lawrin at mysql dot com, (QA, Development)

== Meetings ==

* 22.05.2008 - Technical Meeting of the entire Development team
* 29.04.2008 - [[Database/Drivers/MySQL_Native/Meeting_Minutes | Technical Meeting, Hamburg]]
* 12.02.2008 - Non public Kick-Off Meeting, Hamburg

== Technical Documentation ==

* [[Database/Drivers/MySQL Native/TestingIdeas|Ideas for testing]]

=== Infrastructure ===

* Mailinglists and IRC
** dev@openoffice.org
** irc.freenode.org - #dev.openoffice.org

* OpenOffice 3 CVS
** checkout: cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout -r DEV300_m10 OpenOffice3
** update to CWS code status: cvs update -r cws_dev300_mysqlnative

* [[CWS|CWS (child workspace)]] of Connector/OO.org
** [http://www.openoffice.org/scdocs/ddSSHGuide CVS/SSH instructions]
** Web interface - EIS (Environment Information System) link to CWS: [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmysqlnative mysqlnative]
* Build environment on lsmy3 (MySQL internal)
** [http://tools.openoffice.org/ Introduction on Building OOo]
** For general questions ask on the OOo community mailing lists

* MySQL Connector/OpenOffice.org
** [[Database/Drivers/MySQL Native/Connector/C-OOo-Connect-URL | Connection-URL]]

=== OpenOffice.org ===

* [[Database/Drivers/MySQL_Native/Architecture|OpenOffice.org/StarOffice Base - database driver architecture overview]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%29_Interface|SDBC(X) Interface which has to be supported]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%292MySQL|Mapping of SDBC(X) and MySQL interface]]

Database/Drivers/MySQL Native/Overview

2009-01-19T11:31:24Z

Nixnutz: /* Status and Releases */

== MySQL driver for OpenOffice.org ==

The MySQL driver for OpenOffice.org (also called Connector/OO.org) is a "native" MySQL driver for OpenOffice.org. Before the development of the Conenctor/OO.org, OO.org has used JDBC/ODBC to connect to the MySQL Server. JDBC/ODBC adds an extra level of indirection to the connection and is generally speaking more difficult to install but Connector/OO.org.

Please note that this page is not part of the end-user documentation, check [[http://forge.mysql.com/wiki/Connector_OpenOffice MySQL Forge Connector/OpenOffice] for end-user documentation.. This page is part of the project documentation and used by the development team to coordinate their work.

== Goal ==

Develop a "native" MySQL driver for OpenOffice.org which is at least as feature-complete as other drivers. Complete the task before the release of OO.org 3.0.

== Status and Releases ==

[[Media:Mysql_native_driver_roadmap_rev1.pdf]]

* '''01/2009 - Working towards Alpha'''
* 12/2008 - Internal redesign to run on MySQL Connector/C++
* 05/2008 - 11/2008 - Almost no active development
* 04/2008 - Preview version released for OO.org 2.4
* 02/2008 - Kick-Off Meeting Hamburg
* Before - Native driver development by Georg Richter

== Development team ==

'''Primary contact person'' shown in bold letters.

=== OpenOffice.org/StarOffice Base ===

* '''Frank Schoenheit''', Technical Lead OpenOffice.org/StarOffice Base, firstname dot lastname at sun dot com, (Development)
* Ocke Janssen, firstname dot lastname at sun dot com, (Development)

=== MySQL ===

* Georg Richter, Development Manager - Connectors & Client Connectivity, firstname at mysql dot com, (Development)
* '''Ulf Wendel''', Senior Software Engineer, uwendel at mysql dot com, (QA, Documentation)
* Andrey Hristov, Software Engineer, firstname at mysql dot com, (Development)
* Lawrenty Novitsky, Software Developer, lawrin at mysql dot com, (QA, Development)

== Meetings ==

* 22.05.2008 - Technical Meeting of the entire Development team
* 29.04.2008 - [[Database/Drivers/MySQL_Native/Meeting_Minutes | Technical Meeting, Hamburg]]
* 12.02.2008 - Non public Kick-Off Meeting, Hamburg

== Technical Documentation ==

* [[Database/Drivers/MySQL Native/TestingIdeas|Ideas for testing]]

=== Infrastructure ===

* Mailinglists and IRC
** dev@openoffice.org
** irc.freenode.org - #dev.openoffice.org

* OpenOffice 3 CVS
** checkout: cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout -r DEV300_m10 OpenOffice3
** update to CWS code status: cvs update -r cws_dev300_mysqlnative

* [[CWS|CWS (child workspace)]] of Connector/OO.org
** [http://www.openoffice.org/scdocs/ddSSHGuide CVS/SSH instructions]
** Web interface - EIS (Environment Information System) link to CWS: [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmysqlnative mysqlnative]
* Build environment on lsmy3 (MySQL internal)
** [http://tools.openoffice.org/ Introduction on Building OOo]
** For general questions ask on the OOo community mailing lists

* MySQL Connector/OpenOffice.org
** [[Database/Drivers/MySQL Native/Connector/C-OOo-Connect-URL | Connection-URL]]

=== OpenOffice.org ===

* [[Database/Drivers/MySQL_Native/Architecture|OpenOffice.org/StarOffice Base - database driver architecture overview]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%29_Interface|SDBC(X) Interface which has to be supported]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%292MySQL|Mapping of SDBC(X) and MySQL interface]]

Database/Drivers/MySQL Native/Overview

2009-01-19T11:28:04Z

Nixnutz: /* Status and Releases */

== MySQL driver for OpenOffice.org ==

The MySQL driver for OpenOffice.org (also called Connector/OO.org) is a "native" MySQL driver for OpenOffice.org. Before the development of the Conenctor/OO.org, OO.org has used JDBC/ODBC to connect to the MySQL Server. JDBC/ODBC adds an extra level of indirection to the connection and is generally speaking more difficult to install but Connector/OO.org.

Please note that this page is not part of the end-user documentation, check [[http://forge.mysql.com/wiki/Connector_OpenOffice MySQL Forge Connector/OpenOffice] for end-user documentation.. This page is part of the project documentation and used by the development team to coordinate their work.

== Goal ==

Develop a "native" MySQL driver for OpenOffice.org which is at least as feature-complete as other drivers. Complete the task before the release of OO.org 3.0.

== Status and Releases ==

* '''01/2009 - Working towards Alpha'''
* 12/2008 - Internal redesign to run on MySQL Connector/C++
* 05/2008 - 11/2008 - Almost no active development
* 04/2008 - Preview version released for OO.org 2.4
* 02/2008 - Kick-Off Meeting Hamburg
* Before - Native driver development by Georg Richter

== Development team ==

'''Primary contact person'' shown in bold letters.

=== OpenOffice.org/StarOffice Base ===

* '''Frank Schoenheit''', Technical Lead OpenOffice.org/StarOffice Base, firstname dot lastname at sun dot com, (Development)
* Ocke Janssen, firstname dot lastname at sun dot com, (Development)

=== MySQL ===

* Georg Richter, Development Manager - Connectors & Client Connectivity, firstname at mysql dot com, (Development)
* '''Ulf Wendel''', Senior Software Engineer, uwendel at mysql dot com, (QA, Documentation)
* Andrey Hristov, Software Engineer, firstname at mysql dot com, (Development)
* Lawrenty Novitsky, Software Developer, lawrin at mysql dot com, (QA, Development)

== Meetings ==

* 22.05.2008 - Technical Meeting of the entire Development team
* 29.04.2008 - [[Database/Drivers/MySQL_Native/Meeting_Minutes | Technical Meeting, Hamburg]]
* 12.02.2008 - Non public Kick-Off Meeting, Hamburg

== Technical Documentation ==

* [[Database/Drivers/MySQL Native/TestingIdeas|Ideas for testing]]

=== Infrastructure ===

* Mailinglists and IRC
** dev@openoffice.org
** irc.freenode.org - #dev.openoffice.org

* OpenOffice 3 CVS
** checkout: cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout -r DEV300_m10 OpenOffice3
** update to CWS code status: cvs update -r cws_dev300_mysqlnative

* [[CWS|CWS (child workspace)]] of Connector/OO.org
** [http://www.openoffice.org/scdocs/ddSSHGuide CVS/SSH instructions]
** Web interface - EIS (Environment Information System) link to CWS: [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmysqlnative mysqlnative]
* Build environment on lsmy3 (MySQL internal)
** [http://tools.openoffice.org/ Introduction on Building OOo]
** For general questions ask on the OOo community mailing lists

* MySQL Connector/OpenOffice.org
** [[Database/Drivers/MySQL Native/Connector/C-OOo-Connect-URL | Connection-URL]]

=== OpenOffice.org ===

* [[Database/Drivers/MySQL_Native/Architecture|OpenOffice.org/StarOffice Base - database driver architecture overview]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%29_Interface|SDBC(X) Interface which has to be supported]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%292MySQL|Mapping of SDBC(X) and MySQL interface]]

Database/Drivers/MySQL Native/Overview

2009-01-19T11:27:43Z

Nixnutz: /* Status and Releases */

== MySQL driver for OpenOffice.org ==

The MySQL driver for OpenOffice.org (also called Connector/OO.org) is a "native" MySQL driver for OpenOffice.org. Before the development of the Conenctor/OO.org, OO.org has used JDBC/ODBC to connect to the MySQL Server. JDBC/ODBC adds an extra level of indirection to the connection and is generally speaking more difficult to install but Connector/OO.org.

Please note that this page is not part of the end-user documentation, check [[http://forge.mysql.com/wiki/Connector_OpenOffice MySQL Forge Connector/OpenOffice] for end-user documentation.. This page is part of the project documentation and used by the development team to coordinate their work.

== Goal ==

Develop a "native" MySQL driver for OpenOffice.org which is at least as feature-complete as other drivers. Complete the task before the release of OO.org 3.0.

== Status and Releases ==

'''* 01/2009 - Working towards Alpha'''
* 12/2008 - Internal redesign to run on MySQL Connector/C++
* 05/2008 - 11/2008 - Almost no active development
* 04/2008 - Preview version released for OO.org 2.4
* 02/2008 - Kick-Off Meeting Hamburg
* Before - Native driver development by Georg Richter

== Development team ==

'''Primary contact person'' shown in bold letters.

=== OpenOffice.org/StarOffice Base ===

* '''Frank Schoenheit''', Technical Lead OpenOffice.org/StarOffice Base, firstname dot lastname at sun dot com, (Development)
* Ocke Janssen, firstname dot lastname at sun dot com, (Development)

=== MySQL ===

* Georg Richter, Development Manager - Connectors & Client Connectivity, firstname at mysql dot com, (Development)
* '''Ulf Wendel''', Senior Software Engineer, uwendel at mysql dot com, (QA, Documentation)
* Andrey Hristov, Software Engineer, firstname at mysql dot com, (Development)
* Lawrenty Novitsky, Software Developer, lawrin at mysql dot com, (QA, Development)

== Meetings ==

* 22.05.2008 - Technical Meeting of the entire Development team
* 29.04.2008 - [[Database/Drivers/MySQL_Native/Meeting_Minutes | Technical Meeting, Hamburg]]
* 12.02.2008 - Non public Kick-Off Meeting, Hamburg

== Technical Documentation ==

* [[Database/Drivers/MySQL Native/TestingIdeas|Ideas for testing]]

=== Infrastructure ===

* Mailinglists and IRC
** dev@openoffice.org
** irc.freenode.org - #dev.openoffice.org

* OpenOffice 3 CVS
** checkout: cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout -r DEV300_m10 OpenOffice3
** update to CWS code status: cvs update -r cws_dev300_mysqlnative

* [[CWS|CWS (child workspace)]] of Connector/OO.org
** [http://www.openoffice.org/scdocs/ddSSHGuide CVS/SSH instructions]
** Web interface - EIS (Environment Information System) link to CWS: [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmysqlnative mysqlnative]
* Build environment on lsmy3 (MySQL internal)
** [http://tools.openoffice.org/ Introduction on Building OOo]
** For general questions ask on the OOo community mailing lists

* MySQL Connector/OpenOffice.org
** [[Database/Drivers/MySQL Native/Connector/C-OOo-Connect-URL | Connection-URL]]

=== OpenOffice.org ===

* [[Database/Drivers/MySQL_Native/Architecture|OpenOffice.org/StarOffice Base - database driver architecture overview]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%29_Interface|SDBC(X) Interface which has to be supported]]
* [[Database/Drivers/MySQL_Native/SDBC%28X%292MySQL|Mapping of SDBC(X) and MySQL interface]]

Database/Drivers/MySQL Native/Known Problems

2009-01-12T20:05:45Z

Nixnutz: /* change table fildtype in edit view not possible */

Database/Drivers/MySQL Native/Known Problems

2009-01-12T17:40:31Z

Nixnutz: /* fildtype is changed after saving */

Database/Drivers/MySQL Native/Known Problems

2009-01-12T17:39:45Z

Nixnutz: /* fildtype is changed after saving */