Issue 119  has been merged into this issue.

 Issue 187  has been merged into this issue.

 Issue 492  has been merged into this issue.

 Issue 507  has been merged into this issue.

 Issue 566  has been merged into this issue.

 Issue 261  has been merged into this issue.

 Issue 662  has been merged into this issue.

 Issue 672  has been merged into this issue.

r2244 merges the export redesign branch back into trunk and although it is not yet complete it does implement 
the majority of these requests.

SQL export is now very slow compared to previous versions.
The new features are "nice" but the export of a 300MB DB use to take 3 or 4min and now takes over 15min.

First of all, the new export window is kind of confusing. It took me a couple of clicks to figure out to uncheck S & 
D columns I had to check on the boxes on the side, not the global check/uncheck boxes.

Second, upon selecting items for export, I get the spinning beachball of death for a few minutes (and this is just 
for exporting one relatively small table), and if the app recovers, the export takes a super long time.

I understand that using nightlies means living on the bleeding edge, but I'd say this feature wasn't quite ready for 
public consumption. I've had to go back to a week old build.

Hi serpicolugnut,

Thanks for taking the time to test it out and provide feedback.

I've identified the cause of the beachballing, but out of curiosity, can I ask how many tables there were in the 
database that you experienced the issue? I'm assuming it was in the hundreds as the number of tables is the 
root cause.

Cheers

Stuart

Rowan has kindly fixed the SQL export's progress indicator as well as the use of incorrect extension when 
compressing dumps in r2253 and the beachballing issue when selecting/deselecting tables on the export dialog 
has been fixed in r2254.

Hello Stuart02,

The SQL export is as fast as before.  197 tables in a couple of minutes.
I find the new export interface relatively useful and easy to use.
I have not tested the other export formats.

Stuart - I'm trying to export just one table, albeit a larger (30MB or so) one. However, with only 1 table selected 
(and both Structure and Drop Table turned off in the export window), it still tries to export every table in the 
database (at least, the progress indicator goes through each table). The final output reveals that both Structure 
and Drop Table Syntax are included in the export, even though I've unchecked them in the Include sidebar, which 
is the only way apparently to turn them all off (my database has hundreds of tables).

So, it looks like the bug(s) are:

1) Unchecking "Structure" and "Drop Table Syntax" from the export sidebar just remove those options from the 
list of tables that can be exported, but don't actually remove them from being exported. There needs to be a way 
to check/uncheck all for the Structure and Drop Table Syntax columns like there is for content.

2) You can't name your files, and since Sequel Pro now names every file with a format of Y-M-D, multiple exports 
in the same day produce files that overwrite the previously written file that day. Not good.

Hope this helps.

Hey serpicolugnut,

Thanks for the feedback, I appreciate you taking the time to provide it.

With regard to the points you made, I've also noticed issue (1) and am currently working on fixing it. It seems that 
the complex interface validation is causing the problem. For issue (2) see my response to  issue #712  that you 
logged.

Thanks again.

Cheers

Stuart 

r2289 addresses the "Structure" and "Drop Table Syntax" interaction - the checkboxes on the right are now 
respected, and when they are enabled the select/deselect all toggles will affect *all* checkboxes.

r2291 improves the SQL exporter further, resolving a number of issues with more recent code changes on trunk - 
view, procedure and function exports should work correctly again, triggers should be exported even if content is 
disabled, and a number of other tweaks have been made.

That should resolve all remaining issues with the actual generated SQL, and also tweaks CSV formats.

Still to be implemented/fixed:

+  Issue #742 
+ Fix the resizing of UI controls when both the custom filename and advanced options views are displayed.

The export dialog seems to inconsistently remember things like the export path and the filename tokenization, especially when switching between databases.

It seems every time upon showing the dialog after switching databases I have to reset the path from the default (the desktop), and about half the time I have to re-do the filename tokenization.

Those should be stickier. The Apple HI guidelines are pretty clear about the types of things that should default to their "last used" state. I'd refer to those guidelines when evaluating how that dialog should behave.

Preserving the selected export path has been improved in r2368 and r2394.

Every time I set the Customize Filename field on CSV export options, there are 2 files that are generated, the one that I've asked for, and another file with null string concatenated to its end, see screenshot.

	Screen shot 2010-07-08 at 8.53.59 PM.png 66.7 KB   View   Download

Hi,

Thanks for the report. Can I ask what revision you're using?

Cheers

Still to be implemented/fixed:

+  Issue 742 
+  Issue 747 

+ Convert our XML output format to standard MySQL XML format. See:

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_xml

Just downloaded the latest Nightly build 2450, and tried it again and it still have duplicate files. so I guess the latest build has this problem too.
Eldad.

eldad - thanks for reporting that; it was an issue with Filtered Results exports, I believe.  Should be fixed as of r2462 :)

Thanks Rowan :)

Just a reminder for you to add some "smarts" to the export sheet so that when you're working in the query editor and you select Export it selects "Query Results" instead of "Tables".

@avenjamin: Implemented in r2476

I'm running the CAalpha4 build.  I tried to run an export yesterday and it allowed me to set the options (SQL export) and initiate the export.  Then the status window opened, stated "Writing..." created the file (of 0 byte size) and just sat there.  I hit cancel and restarted the export multiple times, but it didn't help.  Then I quit and restarted CAalpha4, and then it ran the export as expected.

Also, CAalpha4 doesn't seem to prompt you if you're going to overwrite a file.  Seems like that's something that's missing....

@rdshedd: This is a known issue, see  issue #742 .

 Issue #742  has been fixed in r2520.

Still to be fixed:

+ Look into custom filename issues
+ Re-enable Gzip and Bzip2 file compression as well as CSV and XML file headers for files that are overwritten. See r2581.

Closing as the new export architecture is fairly stable now. Any new issues should be reported by opening a new issue.

I'm running a nightly, I still can't import my XML file exported from the last build of Sequel Pro. Where do I find the option to get this data back into the server?

Thanks,
Gray.

Hi Gray,

XML currently isn't a supported import format - the export dialog now warns of that.  Instead it's provided purely for use with other systems.

There are some script solutions out there for loading XML into MySQL which you may have luck with if you really need it… LOAD_FILE may work, and otherwise 5.1 includes improved XML tools.