Description: ------------ MDB assumes that any text type field with a length defined must be of type Char. Since some RDBMS support longer sized text fields, the text type should be customized for every RDBMS supported. The following modification takes the assumption that sized text fields smaller than 64 should be stored as CHAR (no dynamic allocation) and longer as VARCHAR or TEXT if they are bigger. Here is the code for MySQL: function getTextDeclaration($name, $field) { $qry = $name; if ($field['length']>0 && $field['length']<64) $qry .= " CHAR({$field['length']})"; else if ($field['length']>=64 && $field['length']<=256) $qry .= " VARCHAR({$field['length']})"; else $qry .= " TEXT"; $qry .= (isset($field['default'])?' DEFAULT'.$this->getTextValue($field['default']):'').(isset($field['notnull'])?' NOT NULL':''); return $qry; } For Oracle 8+ it should look like this (I haven't tested it): function getTextDeclaration($name, $field) { $qry = $name; if ($field['length']>0 && $field['length']<64) $qry .= " CHAR({$field['length']})"; else if ($field['length']>=64 && $field['length']<=4000) $qry .= " VARCHAR2({$field['length']})"; else $qry .= " CLOB"; $qry .= (isset($field['default'])?' DEFAULT'.$this->getTextValue($field['default']):'').(isset($field['notnull'])?' NOT NULL':''); return $qry; } PGSQL and FrontBase do handle CHAR and VARCHAR as a CLOB (1gb+) so a simple VARCHAR($field['length']) will do for it. FireBird supports upto 64Kb CHAR and VARCHAR types. MsSQL says in it's documentation that the maximum size is 8000 for CHAR and VARCHAR fields. ciao, ivan

Well the main reason why things are the way they are is that there is datatype "clob". However I guess it doesnt hurt to allow the maximum supported field type which does not require any special fetching methods. I actually dont know if you have to use the LOB API to fetch a clob from oracle.

MDB is deprecated, new features should go into MDB2.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.