Export issues, possible bug?

[chp]

I have a database that is about 13MB with maybe 10-15 tables that I need to export to move into a system that only allows CSV files. I have set up the php config file to allow for a 180MB upload and post, with time and memory settings more than adequate. I've not been able to find any relevant setting in Apache or MySQL configs. I'm still having 2 problems with this. Note that I'm not at all familiar with command line work, so would prefer to use phpMyAdmin.

1. If I export using either CSV or CSV for Excel, the export succeeds but I get one spreadsheet with each table of data appended at the bottom of the previous table. Not good.

2. If I export using OpenDocument Spreadsheet, I get the following: "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 110878504 bytes) in C:\xampp\phpMyAdmin\libraries\zip.lib.php on line 139." I've also tried a .htaccess file with adequate settings for import and export but no luck. I don't understand why I would be encountering any filesize or memory limits given my settings.

3. I can split the export into 2 or three separate files. In this case, however, there is one table that still gives me problems with OpenDocument Spreadsheet. When I try to open this particular table with OpenOffice I get an error: "Format error discovered in the file in sub-document content.xml at 21,1899757(row,col.)" If I export this table as CSV, though, both Excel and OpenOffice can open it fine. There does not appear to be any problems with the data and file when it's in CSV. This is where I wonder if there could be a bug in the OpenDocument exporter.

Is there a way to get the export to Excel to work properly (as separate spreadsheets) without having to export each table separately? Are issues 2 and 3 perhaps related?

Thanks so much for any help.

[Nobbie]

1. If I export using either CSV or CSV for Excel, the export succeeds but I get one spreadsheet with each table of data appended at the bottom of the previous table. Not good.

This is due to your Export, obviously you use a script or function that exports either the whole database or even a bunch of tables into one document. You must do this seperately for each table. If you are skilled enough, you could write your own Export function (with PHP).

2. If I export using OpenDocument Spreadsheet, I get the following: "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 110878504 bytes) in C:\xampp\phpMyAdmin\libraries\zip.lib.php on line 139." I've also tried a .htaccess file with adequate settings for import and export but no luck. I don't understand why I would be encountering any filesize or memory limits given my settings.

Looks like you have an option for zipping the output (or similar), which seems to run internally in the memory and gets exhausted due to the table size. Either dont zip the files or apply more memory to PHP (this is an option in php.ini).

3. I can split the export into 2 or three separate files. In this case, however, there is one table that still gives me problems with OpenDocument Spreadsheet. When I try to open this particular table with OpenOffice I get an error: "Format error discovered in the file in sub-document content.xml at 21,1899757(row,col.)" If I export this table as CSV, though, both Excel and OpenOffice can open it fine. There does not appear to be any problems with the data and file when it's in CSV. This is where I wonder if there could be a bug in the OpenDocument exporter.

Take an editor and open the corresponding files and have a look, what is mentioned by this error. We dont have the output here. After you know, what is happening there, you might decide on your own if this is a bug or a problem in your table.

[chp]

2. If I export using OpenDocument Spreadsheet, I get the following: "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 110878504 bytes) in C:\xampp\phpMyAdmin\libraries\zip.lib.php on line 139." I've also tried a .htaccess file with adequate settings for import and export but no luck. I don't understand why I would be encountering any filesize or memory limits given my settings.

Looks like you have an option for zipping the output (or similar), which seems to run internally in the memory and gets exhausted due to the table size. Either dont zip the files or apply more memory to PHP (this is an option in php.ini).

I specifically avoided choosing the option to zip the file. Is it possible there's a setting in php.ini that forces output to be zipped? The resulting files for all exports (including the other OpenDocument files that WERE openable) were not zipped, even if this one was. Doesn't make sense to me. But...the OpenDocument standard is an xml compressed file type, isn't it? Maybe that's causing a problem? If so, why only this one table and not the others which all exported fine using OpenDocument?

3. I can split the export into 2 or three separate files. In this case, however, there is one table that still gives me problems with OpenDocument Spreadsheet. When I try to open this particular table with OpenOffice I get an error: "Format error discovered in the file in sub-document content.xml at 21,1899757(row,col.)" If I export this table as CSV, though, both Excel and OpenOffice can open it fine. There does not appear to be any problems with the data and file when it's in CSV. This is where I wonder if there could be a bug in the OpenDocument exporter.

Take an editor and open the corresponding files and have a look, what is mentioned by this error. We dont have the output here. After you know, what is happening there, you might decide on your own if this is a bug or a problem in your table.

There is no error noted that I can see on a quick look. OpenOffice throws an error window with the error message I quoted. The file is unopened. When I open it with NotePad, I get gibberish (to me). Here's a section:

PK  -·1D…l9Š, .  mimetypeÁ Àl&ч„RIkþî8s™p[øx®\V א»áM•¬5þPK  -·1Duü¹Võ Í.ã  content.xmlìýß’G’æ‰ÞÈ¼ƒKKËœnÚÍÌÍÿõlÏ

DÉæ
Ø]Ò{ÓD‰ÜJD`#¬Á\µÌȾÄÈî^Ôõ<EÕ›ô“w‡³áî„}nªÁ¯$¤ª" °TXz¸þ\MõÓÿü_þëË›ì‡Ýñöú°ÿßþÊÜËÿ*Ûퟮ®÷ßÿoõúî»MýWÿåþóá»ï®ŸïÚ«Ãó×/wû»ÍóÃþ®û߬ûËûÛöíŸvæÇ}{ØÞ^߶ûíËÝm{÷¼=¼Úíü[

It goes on like that for many many lines.