Hi DBVis team,
It would be very useful, if we could use the export functionality of the SQL Editor data grid to export "all" data regardless of the max row setting.
I develop a SQL statement but only retrieve 1000 rows as a preview. Now I want to export all the data that the statement can retrieve, not just the 1000 rows from the preview. The only way to do that afaik is:
1) set max rows to -1, load all the data into the data grid and then hit export
--> this is not optimal at all, because it can blow up DBVis' internal memory if there are big amounts of data
2) open the export grid function, set the export options accordingly --> copy settings to clipboard, cancel the dialog, then copy the settings in front of the SQL statement, change max rows to -1 and hit execute
--> this is super inefficient and time consuming and also some of the settings that are set in the options are not correctly copied to the clipboard (e.g. destination file name) so you have to edit the inserted export statements again
What would be great is a max row setting in the export grid dialog, where I can put -1 in to export all data, not just the 1000 rows from the grid itself.
Maybe this is worth considering, it surely would save a lot of time.
I suggest that you have a look at the @export command and the @set maxrows command:
The @export command does not consume memory like loading the complete result into DbVisualizer does, and combining it with the @set maxrows command you can override the Max Rows field just for the export.
Okay, I see your point. We will discuss adding what you suggest.
Has there been any progress on this request? I recently started evaluating DbVis and this exact issue is my only complaint so far.
The @export and @set commands, while useful, are a clumsy way of accomplishing a full export for several reasons:
-I don't want to have to type or copy/paste a path, especially when that path is 7-8 folders deep on a shared network drive
-I very rarely want to export just a subset of data. Having to change the maxrows setting - either by command or by click - is awkward. Having to then change it back is even more awkward.
-If I forget to comment out the @export command after a change to the query, I end up over-writing the existing file. My coworker (also evaluating the prodcut) did that this morning with a 2.5 million row data file that took an hour and a half to export.
Other than this it seems like a great product!