Description: ------------ Hi again. When I import an XML file like <initialization> <insert> ... <field> <name>search_string</name> <value>I'm cut!!"leaves just me</value> </field> </insert> </initialization> I get exactly what the sample data above already suggests (everything until " included is left out). For your convenience I already tracked this bug down to a problem in the XML parser. In the function cdataHandler(), the case 'database-table-initialization-update-field-value' should read $this->init_field['group'] = array('type' => 'value', 'data' => $this->init_field['group']['data'] . $data); instead of $this->init_field['group'] = array('type' => 'value', 'data' => $data); to preserve already read data. Expected result: ---------------- Inserted data is: I'm cut!!"leaves just me Actual result: -------------- Inserted data is: leaves just me

Hi Florian, Thank you for submitting this bug, but this is already a known issue. To get it really fixed you have to worry not just about "field-value" but "field-function-value" as well as a few others. That's where we find the problem: $this->init_function['arguments'][] = array('type' => 'value', 'data' => $data); How to tell when we are parsing a new argument or something after the entity ? Just like what is done for "field-value", we would have to create a temporary variable and assign it to the 'arguments' array as we reach the end tag of "field-function-value". But this would require a lot of code rewriting in a parser that would be replaced when we move to php5. I am making it a feature request. regards, iGor.

Well, functions are a whole different issue and I'd say that they are used rather rarely. A field value is something rather basic though that shouldn't come with any significant flaws like this one.

I should also add that this bug prevents exporting data to XML to later import it on another database (or basically any database initialisation with XML if you have quotes or other special chars in your data). The biggest problem is that there is not even a workaround. Sure " can be replaced with " in this case, but that is not valid for < or >. So while you might not be able to fix the bug for all imaginable situations, it should at least be fixed for the most common one.

don't worry man ;) I am still working on Bug #11604. I will partially fix this one ASAP. regards, iGor.

By the way, you can workaround setting the option 'parser' to 'MDB2_Schema_Parser2', or just: $schema->setOption('parser', 'MDB2_Schema_Parser2'); Be aware the limitations of Parser2 stated in the end user documentation. regards, iGor.

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. I am closing this bug as this is addressed by Parser2. It is now fixed for "field-value" cases in Parser. Just let me know if you still have any issue.

Sorry for being impatient ;) Works now (tried with the same parser from before), thanks.