http://pear.php.net/bugs/search.php?cmd=display&package_name%5B0%5D=MDB2_Driver_mysql Search Results en-us pear-webmaster@lists.php.net pear-webmaster@lists.php.net hourly 1 2000-01-01T12:00+00:00 http://pear.php.net/gifs/pearsmall.gif http://pear.php.net/bugs http://pear.php.net/bugs/23783 MDB2_Driver_mysql Feature/Change Request Reported by joneum 2018-12-21T09:13:23+00:00 PHP: HEAD SVN-2018-12-21 OS: FreeBSD Package Version: 1.5.0b4 Description: ------------ Is there a chance to make this PHP 7.x ready?]]> MDB2_Driver_mysql Feature/Change Request Reported by joneum 2018-12-21T09:13:23+00:00 PHP: HEAD SVN-2018-12-21 OS: FreeBSD Package Version: 1.5.0b4 Description: ------------ Is there a chance to make this PHP 7.x ready?]]> 2018-12-21T09:13:23+00:00 joneum &#x61;&#116; FreeBSD &#x64;&#111;&#x74; org MDB2_Driver_mysql Feature/Change Request http://pear.php.net/bugs/20379 MDB2_Driver_mysql Bug Reported by nik600 2014-08-29T15:23:15+00:00 PHP: Irrelevant OS: Linux Package Version: 1.4.1 Description: ------------ As shown in the test, if you want to use transactions having multiple mdb2 instances these doesn't works. This happends because in the method _getServerCapabilities() there is a static variable to avoid multiple checks to the serverCapabilities... and this is ok BUT in the constructor of the class you set a default value to false for $this->start_transaction to false. So, the first time the $this->start_transaction is set to false, then the method _getServerCapabilities set it to true, and the transaction start correctly. The second time the start_transaction is set to false again, but the metod _getServerCapabilities doesn't check as already_checked is true, and as start_transaction is set to false the metod beginTransaction does a SET AUTOCOMMIT = 1 instead of a START TRANSACTION To fix the problem you can use an attribute of the class instead of a static variable. Test script: --------------- <?php include ("MDB2.php"); /* * sql for creating the table: * CREATE TABLE IF NOT EXISTS `foo_table` ( `foo_field` int(11) NOT NULL) ENGINE=InnoDB; */ $connstring="mysql://root:mypass@127.0.0.1/test?new_link=true"; $mdb2 =& MDB2::connect($connstring); $mdb2->beginTransaction(); $mdb2->query("INSERT INTO foo_table (foo_field) VALUES ('1')"); $mdb2->rollback(); $mdb3 =& MDB2::connect($connstring); $mdb3->beginTransaction(); $mdb3->query("INSERT INTO foo_table (foo_field) VALUES ('2')"); $mdb3->rollback(); ?> Expected result: ---------------- no rows must be insert into the table Actual result: -------------- the row with value 2 is insert into the table]]> MDB2_Driver_mysql Bug Reported by nik600 2014-08-29T15:23:15+00:00 PHP: Irrelevant OS: Linux Package Version: 1.4.1 Description: ------------ As shown in the test, if you want to use transactions having multiple mdb2 instances these doesn't works. This happends because in the method _getServerCapabilities() there is a static variable to avoid multiple checks to the serverCapabilities... and this is ok BUT in the constructor of the class you set a default value to false for $this->start_transaction to false. So, the first time the $this->start_transaction is set to false, then the method _getServerCapabilities set it to true, and the transaction start correctly. The second time the start_transaction is set to false again, but the metod _getServerCapabilities doesn't check as already_checked is true, and as start_transaction is set to false the metod beginTransaction does a SET AUTOCOMMIT = 1 instead of a START TRANSACTION To fix the problem you can use an attribute of the class instead of a static variable. Test script: --------------- <?php include ("MDB2.php"); /* * sql for creating the table: * CREATE TABLE IF NOT EXISTS `foo_table` ( `foo_field` int(11) NOT NULL) ENGINE=InnoDB; */ $connstring="mysql://root:mypass@127.0.0.1/test?new_link=true"; $mdb2 =& MDB2::connect($connstring); $mdb2->beginTransaction(); $mdb2->query("INSERT INTO foo_table (foo_field) VALUES ('1')"); $mdb2->rollback(); $mdb3 =& MDB2::connect($connstring); $mdb3->beginTransaction(); $mdb3->query("INSERT INTO foo_table (foo_field) VALUES ('2')"); $mdb3->rollback(); ?> Expected result: ---------------- no rows must be insert into the table Actual result: -------------- the row with value 2 is insert into the table]]> 2014-08-29T15:23:15+00:00 nik600 &#x61;&#116; gmail &#x64;&#111;&#x74; com MDB2_Driver_mysql Bug http://pear.php.net/bugs/20301 MDB2_Driver_mysql Bug Reported by newpear2014 2014-06-19T00:33:54+00:00 PHP: 5.5.13 OS: Centos 6.5 Package Version: 1.4.1 Description: ------------ # pear install MDB2_Driver_mysql downloading MDB2_Driver_mysql-1.4.1.tgz ... Starting to download MDB2_Driver_mysql-1.4.1.tgz (36,481 bytes) ..........done: 36,481 bytes could not extract the package.xml file from "/tmp/pear/download/MDB2_Driver_mysql-1.4.1.tgz" Download of "pear/MDB2_Driver_mysql" succeeded, but it is not a valid package archive Error: cannot download "pear/MDB2_Driver_mysql" Download failed install failed]]> MDB2_Driver_mysql Bug Reported by newpear2014 2014-06-19T00:33:54+00:00 PHP: 5.5.13 OS: Centos 6.5 Package Version: 1.4.1 Description: ------------ # pear install MDB2_Driver_mysql downloading MDB2_Driver_mysql-1.4.1.tgz ... Starting to download MDB2_Driver_mysql-1.4.1.tgz (36,481 bytes) ..........done: 36,481 bytes could not extract the package.xml file from "/tmp/pear/download/MDB2_Driver_mysql-1.4.1.tgz" Download of "pear/MDB2_Driver_mysql" succeeded, but it is not a valid package archive Error: cannot download "pear/MDB2_Driver_mysql" Download failed install failed]]> 2014-06-19T00:33:54+00:00 aturley &#x64;&#111;&#x74; ra &#x61;&#116; gmail &#x64;&#111;&#x74; com MDB2_Driver_mysql Bug http://pear.php.net/bugs/20263 MDB2_Driver_mysql Bug Reported by gzuki 2014-05-03T16:49:36+00:00 PHP: Irrelevant OS: Ubuntu Package Version: 1.5.0b4 Description: ------------ Hi, if you have newlines at the end of a text (bigtext field) the driver in this versions doesnt return that. With 1.4.1 all works fine. Test script: --------------- $wheresql="WHERE ".$db->quoteIdentifier($idname)."='".$db->escape($id)."'"; $sql="SELECT * FROM ".$db->quoteIdentifier($tablename)." $wheresql"; $res=$db->query($sql); if (!MDB2::isError($res)) { $entry=$res->fetchAll(); if (count($entry)>0) { $rentry=$entry[0]; } else { //no result $rentry=array(); } } Expected result: ---------------- all between the "###" ### newlinetest ### Actual result: -------------- all between the "###" ### newlinetest ###]]> MDB2_Driver_mysql Bug Reported by gzuki 2014-05-03T16:49:36+00:00 PHP: Irrelevant OS: Ubuntu Package Version: 1.5.0b4 Description: ------------ Hi, if you have newlines at the end of a text (bigtext field) the driver in this versions doesnt return that. With 1.4.1 all works fine. Test script: --------------- $wheresql="WHERE ".$db->quoteIdentifier($idname)."='".$db->escape($id)."'"; $sql="SELECT * FROM ".$db->quoteIdentifier($tablename)." $wheresql"; $res=$db->query($sql); if (!MDB2::isError($res)) { $entry=$res->fetchAll(); if (count($entry)>0) { $rentry=$entry[0]; } else { //no result $rentry=array(); } } Expected result: ---------------- all between the "###" ### newlinetest ### Actual result: -------------- all between the "###" ### newlinetest ###]]> 2014-05-03T16:49:36+00:00 mariogzuk &#x61;&#116; technikz &#x64;&#111;&#x74; de MDB2_Driver_mysql Bug http://pear.php.net/bugs/20215 MDB2_Driver_mysql Bug Reported by solaris 2014-03-06T04:33:45+00:00 PHP: Irrelevant OS: Microsoft Windows [Version 6.1.7 Package Version: 1.5.0b4 Description: ------------ Many of MDB2's methods rely on $definition['collation'] whereas in Reverse_mysql::getTableFieldDefinition() incorrect $definition['collate'] returned. In particular, it brakes Manager_mysql::alterTable(): it just specifies a character set ignoring a column's collation (for column change cases). Changing character set without collation clears it from the column. There are also 2 other places where 'collate' in $options should be replaced with 'collation': - Manager_mysql::createTable() and - Manager_mysql::createSequence()]]> MDB2_Driver_mysql Bug Reported by solaris 2014-03-06T04:33:45+00:00 PHP: Irrelevant OS: Microsoft Windows [Version 6.1.7 Package Version: 1.5.0b4 Description: ------------ Many of MDB2's methods rely on $definition['collation'] whereas in Reverse_mysql::getTableFieldDefinition() incorrect $definition['collate'] returned. In particular, it brakes Manager_mysql::alterTable(): it just specifies a character set ignoring a column's collation (for column change cases). Changing character set without collation clears it from the column. There are also 2 other places where 'collate' in $options should be replaced with 'collation': - Manager_mysql::createTable() and - Manager_mysql::createSequence()]]> 2014-03-06T04:33:45+00:00 tonya &#x61;&#116; erezlife &#x64;&#111;&#x74; com MDB2_Driver_mysql Bug http://pear.php.net/bugs/19625 MDB2_Driver_mysql Bug Reported by hschletz 2012-09-29T15:56:04+00:00 PHP: Irrelevant OS: Package Version: SVN Description: ------------ _createFKTriggers() contains a hack to raise an error on FK constraint violation by calling a (hopefully) nonexistent procedure. The name of that procedure is composed of a descriptive message and the table name. Since MySQL limits procedure names to 64 characters, this fails with Error 1059 if the table name is longer than about 16 characters: Identifier name 'update_ON_TABLE_table_name_with more_than_16_characters_VIOLATES_FOREIGN_KEY_CONSTRAINT' is too long I have attached a patch that reduces the risk by shortening the message (and still being meaningful), so that the limit is not exceeded that easily. That's far from perfect because the table name limit is only extended, not removed. The procedure name should better be truncated to 64 characters, or use an alternative hack to deliver an error message that is not subject to that limitation.]]> MDB2_Driver_mysql Bug Reported by hschletz 2012-09-29T15:56:04+00:00 PHP: Irrelevant OS: Package Version: SVN Description: ------------ _createFKTriggers() contains a hack to raise an error on FK constraint violation by calling a (hopefully) nonexistent procedure. The name of that procedure is composed of a descriptive message and the table name. Since MySQL limits procedure names to 64 characters, this fails with Error 1059 if the table name is longer than about 16 characters: Identifier name 'update_ON_TABLE_table_name_with more_than_16_characters_VIOLATES_FOREIGN_KEY_CONSTRAINT' is too long I have attached a patch that reduces the risk by shortening the message (and still being meaningful), so that the limit is not exceeded that easily. That's far from perfect because the table name limit is only extended, not removed. The procedure name should better be truncated to 64 characters, or use an alternative hack to deliver an error message that is not subject to that limitation.]]> 2012-09-29T15:56:04+00:00 holger &#x64;&#111;&#x74; schletz &#x61;&#116; web &#x64;&#111;&#x74; de MDB2_Driver_mysql Bug http://pear.php.net/bugs/19304 MDB2_Driver_mysql Bug Reported by daftmav 2012-02-24T03:50:12+00:00 PHP: 5.3.2 OS: Ubuntu Package Version: Description: ------------ Some values from bit fields are incorrectly returned as zero (or null?). Not sure why it's only doing this with some bits 'on', but not when other bits are also 'on'. Makes me think it has something to do with bits being returned as weird ascii characters from the DB and MDB2 filters or can't handle some of them? Stable 4.2.1 does not have this issue and correctly returns all bit values. Tested with MDB2 2.5.0b3 and MDB2_Driver_mysql 1.5.0b3 Also tried 2.5.0b2 but it's the same. I found it because I'm moving a site to a php5 setup and 2.4.1 has al sorts of errors with it so I tried the beta. Test script: --------------- A table with some sample data included: http://pastebin.com/ckvX78u4 Because bit values are returned like actual bits, I've added a simple test script which shows the problem in a more readable format. Expected result: ---------------- 1 [ascii value: 1 ] 00000001 : one 2 [ascii value: 2 ] 00000010 : two 3 [ascii value: 4 ] 00000100 : three 4 [ascii value: 8 ] 00001000 : four 5 [ascii value: 16 ] 00010000 : five 6 [ascii value: 32 ] 00100000 : six 7 [ascii value: 64 ] 01000000 : seven 8 [ascii value: 128 ] 10000000 : eight 9 [ascii value: 3 ] 00000011 : one and two 10 [ascii value: 5 ] 00000101 : one and three 11 [ascii value: 9 ] 00001001 : one and four 12 [ascii value: 17 ] 00010001 : one and five 13 [ascii value: 33 ] 00100001 : one and six 14 [ascii value: 65 ] 01000001 : one and seven 15 [ascii value: 129 ] 10000001 : one and eight Actual result: -------------- Note: row 6 and 11 are wrong (zero): 1 [ascii value: 1 ] 00000001 : one 2 [ascii value: 2 ] 00000010 : two 3 [ascii value: 4 ] 00000100 : three 4 [ascii value: 8 ] 00001000 : four 5 [ascii value: 16 ] 00010000 : five 6 [ascii value: 0 ] 00000000 : six <<<--- zero 7 [ascii value: 64 ] 01000000 : seven 8 [ascii value: 128 ] 10000000 : eight 9 [ascii value: 3 ] 00000011 : one and two 10 [ascii value: 5 ] 00000101 : one and three 11 [ascii value: 0 ] 00000000 : one and four <<<--- zero 12 [ascii value: 17 ] 00010001 : one and five 13 [ascii value: 33 ] 00100001 : one and six 14 [ascii value: 65 ] 01000001 : one and seven 15 [ascii value: 129 ] 10000001 : one and eight]]> MDB2_Driver_mysql Bug Reported by daftmav 2012-02-24T03:50:12+00:00 PHP: 5.3.2 OS: Ubuntu Package Version: Description: ------------ Some values from bit fields are incorrectly returned as zero (or null?). Not sure why it's only doing this with some bits 'on', but not when other bits are also 'on'. Makes me think it has something to do with bits being returned as weird ascii characters from the DB and MDB2 filters or can't handle some of them? Stable 4.2.1 does not have this issue and correctly returns all bit values. Tested with MDB2 2.5.0b3 and MDB2_Driver_mysql 1.5.0b3 Also tried 2.5.0b2 but it's the same. I found it because I'm moving a site to a php5 setup and 2.4.1 has al sorts of errors with it so I tried the beta. Test script: --------------- A table with some sample data included: http://pastebin.com/ckvX78u4 Because bit values are returned like actual bits, I've added a simple test script which shows the problem in a more readable format. Expected result: ---------------- 1 [ascii value: 1 ] 00000001 : one 2 [ascii value: 2 ] 00000010 : two 3 [ascii value: 4 ] 00000100 : three 4 [ascii value: 8 ] 00001000 : four 5 [ascii value: 16 ] 00010000 : five 6 [ascii value: 32 ] 00100000 : six 7 [ascii value: 64 ] 01000000 : seven 8 [ascii value: 128 ] 10000000 : eight 9 [ascii value: 3 ] 00000011 : one and two 10 [ascii value: 5 ] 00000101 : one and three 11 [ascii value: 9 ] 00001001 : one and four 12 [ascii value: 17 ] 00010001 : one and five 13 [ascii value: 33 ] 00100001 : one and six 14 [ascii value: 65 ] 01000001 : one and seven 15 [ascii value: 129 ] 10000001 : one and eight Actual result: -------------- Note: row 6 and 11 are wrong (zero): 1 [ascii value: 1 ] 00000001 : one 2 [ascii value: 2 ] 00000010 : two 3 [ascii value: 4 ] 00000100 : three 4 [ascii value: 8 ] 00001000 : four 5 [ascii value: 16 ] 00010000 : five 6 [ascii value: 0 ] 00000000 : six <<<--- zero 7 [ascii value: 64 ] 01000000 : seven 8 [ascii value: 128 ] 10000000 : eight 9 [ascii value: 3 ] 00000011 : one and two 10 [ascii value: 5 ] 00000101 : one and three 11 [ascii value: 0 ] 00000000 : one and four <<<--- zero 12 [ascii value: 17 ] 00010001 : one and five 13 [ascii value: 33 ] 00100001 : one and six 14 [ascii value: 65 ] 01000001 : one and seven 15 [ascii value: 129 ] 10000001 : one and eight]]> 2012-02-24T17:52:55+00:00 mavdude &#x61;&#116; gmail &#x64;&#111;&#x74; com MDB2_Driver_mysql Bug http://pear.php.net/bugs/18711 MDB2_Driver_mysql Bug Reported by haggholm 2011-08-04T23:22:04+00:00 PHP: Irrelevant OS: Package Version: Description: ------------ nextID() fails to enforce the correct error checking, and thus erroneously treats cleanup failures as critical. See attached patch; it’s pretty trivial.]]> MDB2_Driver_mysql Bug Reported by haggholm 2011-08-04T23:22:04+00:00 PHP: Irrelevant OS: Package Version: Description: ------------ nextID() fails to enforce the correct error checking, and thus erroneously treats cleanup failures as critical. See attached patch; it’s pretty trivial.]]> 2011-08-04T23:22:04+00:00 petter &#x61;&#116; petterhaggholm &#x64;&#111;&#x74; net MDB2_Driver_mysql Bug http://pear.php.net/bugs/16781 MDB2_Driver_mysql Bug Reported by fanwar 2009-11-12T04:21:57+00:00 PHP: 5.2.3 OS: BSD Package Version: 1.4.1 Description: ------------ I'm having a difficult time with MDB2_driver_mysql and getting it to recognize transactions. I have mysql installed with InnoDB tables and when I do a $db->supports['transactions'], it keeps returning false. I checked the supported array and the values are just not set. I'm using version 1.4.1 of the driver. Anyone know what the problem may be? Here is the code I am running: Before Test script: --------------- $conn_string = "{$dbtype}://{$dbuser}:{$dbpass}@{$dbhost}/{$dbname}"; $options = array(); $options['use_transactions'] = true; $options['default_table_type'] = 'InnoDB'; $dbconn =& MDB2::singleton($conn_string, $options); if (PEAR::isError($dbconn)) { getLogger()->log("Error creating db connection: " . $dbconn->getMessage(), CritterSettings::LOG_LEVEL_CRIT); die($dbconn->getMessage()); } //BEGIN TRANSACTION HERE if ($this->db->supports('transactions')) { $this->db->beginTransaction(); } else { throw new Exception("Database is not correctly configured - transactions unsupported"); } //the exception keeps getting thrown Expected result: ---------------- I expect to get true since I am using InnoDB tables and transactions should be supported. Actual result: -------------- I get false and when I print out the supported array, it shows: Nov 11 17:08:01 [info] Array ( [sequences] => emulated [indexes] => 1 [affected_rows] => 1 [summary_functions] => 1 [order_by_text] => 1 [transactions] => [savepoints] => [current_id] => emulated [limit_queries] => 1 [LOBs] => 1 [replace] => 1 [sub_selects] => emulated [auto_increment] => 1 [primary_key] => 1 [result_introspection] => 1 [prepared_statements] => emulated [identifier_quoting] => 1 [pattern_escaping] => 1 [new_link] => 1 )]]> MDB2_Driver_mysql Bug Reported by fanwar 2009-11-12T04:21:57+00:00 PHP: 5.2.3 OS: BSD Package Version: 1.4.1 Description: ------------ I'm having a difficult time with MDB2_driver_mysql and getting it to recognize transactions. I have mysql installed with InnoDB tables and when I do a $db->supports['transactions'], it keeps returning false. I checked the supported array and the values are just not set. I'm using version 1.4.1 of the driver. Anyone know what the problem may be? Here is the code I am running: Before Test script: --------------- $conn_string = "{$dbtype}://{$dbuser}:{$dbpass}@{$dbhost}/{$dbname}"; $options = array(); $options['use_transactions'] = true; $options['default_table_type'] = 'InnoDB'; $dbconn =& MDB2::singleton($conn_string, $options); if (PEAR::isError($dbconn)) { getLogger()->log("Error creating db connection: " . $dbconn->getMessage(), CritterSettings::LOG_LEVEL_CRIT); die($dbconn->getMessage()); } //BEGIN TRANSACTION HERE if ($this->db->supports('transactions')) { $this->db->beginTransaction(); } else { throw new Exception("Database is not correctly configured - transactions unsupported"); } //the exception keeps getting thrown Expected result: ---------------- I expect to get true since I am using InnoDB tables and transactions should be supported. Actual result: -------------- I get false and when I print out the supported array, it shows: Nov 11 17:08:01 [info] Array ( [sequences] => emulated [indexes] => 1 [affected_rows] => 1 [summary_functions] => 1 [order_by_text] => 1 [transactions] => [savepoints] => [current_id] => emulated [limit_queries] => 1 [LOBs] => 1 [replace] => 1 [sub_selects] => emulated [auto_increment] => 1 [primary_key] => 1 [result_introspection] => 1 [prepared_statements] => emulated [identifier_quoting] => 1 [pattern_escaping] => 1 [new_link] => 1 )]]> 2011-03-13T16:44:54+00:00 fanwar &#x61;&#116; gmail &#x64;&#111;&#x74; com MDB2_Driver_mysql Bug http://pear.php.net/bugs/16557 MDB2_Driver_mysql Bug Reported by hschletz 2009-08-31T17:28:49+00:00 PHP: Irrelevant OS: Package Version: CVS Description: ------------ If a column has a NOT NULL attribute and a default value of NULL, getTableFieldDefinition() changes the default to '' for text columns and '0000-00-00 00:00:00' for timestamp columns. This behavior is incorrect and not portable. There is no relationship between a NOT NULL constraint and a default value. MySQL reports a NULL default because the default is NULL, not '' or '0000-00-00 00:00:00'. The attached patch leaves the null value untouched. This also reverts the patch from #12336 completely, which says: "MySQL uses '0000-00-00 00:00:00' for any timestamp fields with 'NOT NULL'. This driver should set that for any non-null fields that it finds. This will make it work better with MDB2_Schema." I disagree (the following statements also apply to text columns): - The NOT NULL / DEFAULT NULL combination is expected to force the application to provide valid input data. Depending on server SQL mode, MySQL allows NULL anyway, turns it into a pseudo-NULL value and just throws a warning. See also: http://dev.mysql.com/doc/refman/5.0/en/constraint-invalid-data.html However, this behavior only applies to MySQL and only in a specific server SQL mode. It does not change the column's definition itself and should not leak out to the application, which might run in a different environment that behaves correctly. In this case it's really up to the developer to stop doing stupid things - MySQL with default settings cannot do this for us. - As MDB2_Schema is concerned, I had to disable these implicit conversions to make it work as expected.]]> MDB2_Driver_mysql Bug Reported by hschletz 2009-08-31T17:28:49+00:00 PHP: Irrelevant OS: Package Version: CVS Description: ------------ If a column has a NOT NULL attribute and a default value of NULL, getTableFieldDefinition() changes the default to '' for text columns and '0000-00-00 00:00:00' for timestamp columns. This behavior is incorrect and not portable. There is no relationship between a NOT NULL constraint and a default value. MySQL reports a NULL default because the default is NULL, not '' or '0000-00-00 00:00:00'. The attached patch leaves the null value untouched. This also reverts the patch from #12336 completely, which says: "MySQL uses '0000-00-00 00:00:00' for any timestamp fields with 'NOT NULL'. This driver should set that for any non-null fields that it finds. This will make it work better with MDB2_Schema." I disagree (the following statements also apply to text columns): - The NOT NULL / DEFAULT NULL combination is expected to force the application to provide valid input data. Depending on server SQL mode, MySQL allows NULL anyway, turns it into a pseudo-NULL value and just throws a warning. See also: http://dev.mysql.com/doc/refman/5.0/en/constraint-invalid-data.html However, this behavior only applies to MySQL and only in a specific server SQL mode. It does not change the column's definition itself and should not leak out to the application, which might run in a different environment that behaves correctly. In this case it's really up to the developer to stop doing stupid things - MySQL with default settings cannot do this for us. - As MDB2_Schema is concerned, I had to disable these implicit conversions to make it work as expected.]]> 2009-08-31T17:28:49+00:00 holger &#x64;&#111;&#x74; schletz &#x61;&#116; web &#x64;&#111;&#x74; de MDB2_Driver_mysql Bug http://pear.php.net/bugs/16525 MDB2_Driver_mysql Feature/Change Request Reported by alsal 2009-08-15T03:43:59+00:00 PHP: 5.3.0 OS: Linux Package Version: 1.4.1 Description: ------------ Support for MYSQL's SPATIAL data formats (i.e: GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION)]]> MDB2_Driver_mysql Feature/Change Request Reported by alsal 2009-08-15T03:43:59+00:00 PHP: 5.3.0 OS: Linux Package Version: 1.4.1 Description: ------------ Support for MYSQL's SPATIAL data formats (i.e: GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION)]]> 2009-08-15T19:17:28+00:00 alan &#x61;&#116; y3h &#x64;&#111;&#x74; org MDB2_Driver_mysql Feature/Change Request