DataGrip - Dump Data is disabled


I'm trying to export my query results to CSV or TSV, but I've never been able to use the dump data option, because it is disabled (greyed out).

I've tried registering my license again, and playing around with the data extractor file configurations, but no luck so far.

I might be missing something elemental, any help is appreciated.



Could you tell DataGrip version and database you use?

Did you change schema in a console before dump?

Did you specify a database in data source settings?

Thank you


Hi, thanks for your response. It's DataGrip 2017.1.3, I work with SQL Server.

The problem does appear after switching databases, for example using USE DATABASE2. I'm only able to perform data dump after opening a new console and before changing to another database.

The settings in data source do specify a database, but I often switch to others in the same server through USE command. Once I switch databases I can no longer export to file or clipboard, even if I return to the original database specified in the data source settings.

So my workaround is to open a new console every time I need to work on a different database.

I should note that I've already contacted support, they say "it is expected behavior" at this moment, so I guess I'm just waiting for a fix in a future version.


I have experienced the same problem using v2017.1.4. The Data Dump options are grayed out in both the right-click and toolbar options. They cannot be selected. However, highlighting the result set rows and using Ctrl-C does function properly...i.e. I am getting the insert statements I need.



> Did you change schema in a console before dump?

Yes, I had. My schema changes amounted to selecting new tables to appear under my data source connection.

And I have restarted DG and the data extractor options are now available. So I'm good to go.

Interesting in that I was attempting to data dump from the results window, not from a table. Not sure how schema changes would affect dumping from a results window.

Anywho, have a good one.



> Not sure how schema changes would affect dumping from a results window.

I know it's odd, but in my case it's completely reproducible. I start DG, and Dump options are enabled. As soon as I change schemas with the USE command, or through the UI, they become disabled. They remain disabled until I open a new console or restart DG.


@Javiersn .. same. Its reproducible and I experience the same behaviors/results. It's now in tech's court.


Same issue is occurring for me with a MySQL (technically MariaDB) database.


I have the same problem after update to 2017.2. All dump options are inactive (grey). DB Postgres.



We found out that the problem is in `use` statement in out database console.

Thank you.


Having the same issue.  Seems random, and incredibly frustrating.  No changes, just a greyed out dump option *sometimes*.  


Just started experiencing this issue yesterday... So frustrating!


I already submitted a ticket, but I think I was able to figure out my issue. I am querying against a Redshift data source and when I first open and run a SQL query it lets me export the results but stops working upon re-opening or restarting DG. Then I noticed something - When it runs the query the first time, the tool picks a default schema (upper right-hand corner of the console window) and once it has picked the default schema it stays that way when I re-open the file or DG. So the workaround for that is creating a new console window everytime I want to run a report and only being able to export once before, I have to move to another window if I made any changes to my query.... :(

Looking at the updated help page - section Writing and executing SQL statements / Controlling the schema search path for PostgreSQL and Redshift found here - You can see that you have the option to select which default schema or schemas you want to use when running your SQL, however the list seems to be cut short and does not display all of my schemas in my redshift instance so I am not able to work around this new feature by selecting the schemas used in the query.

In the end, I am not sure why they introduced this default schema selection into the tool, it seems like a 'nice to have', but is unnecessary when querying against multiple schemas as you would from a Redshift instance.


@Ryanl Yeah, my workaround is also opening a new console when I want to switch databases (from the schemas pane) to avoid using the SQL Command 'USE' which causes the problem.

Sadly, the devs are reporting the issue DB-3115 as 'fixed' for version 2017.2.x but I updated and the fix is NOT in that version.


It seems sporadic/random -- sometimes opening a new console works, sometimes it doesn't.  Hugely annoying.


@Rmatsuoka Hi,

We've got some troubles with USE statements. Try the latest DataGrip version (2017.2).
Thank you.



There seems to be some confusion. I've updated to version 2017.2 and I can confirm that the problem is NOT fix in this version.


I can confirm for 2017.2 too :(


@Vasily, I'm using 2017.2 and I just have a simple SELECT * FROM table query and I still can't export the data.


I've actually switched back to PgAdmin3 to do this.  Shows the desperation...


I have also switched to using other tools as well. The worst part is not knowing whether you will be able to export results after waiting for a rather large query to run only to find those options grayed out. 


@Rmatsuoka @Ryanl I agree with you guys, I'm currently using RazorSQL because, as Ryan says, it's a huge waste of time running a large query only to not be able to export the data.


Same problem, can't dump data to CSV. Makes the whole thing pretty useless...


Amusing little behavior here. 

First things first. I execute the Select, not the use statements. The Select is fully qualified with domain and schema. This gives me data to export. The export button is enabled.

When I execute the 'use RTICommon', the export button remains enabled. Nothing changes when I execute it a second and third time; it remains enabled.

When I execute 'use rticommunication', the button is disabled. Nothing changes when I execute it a second and third time; the button remains disabled.

When I execute 'use rticompany', the button remains disabled. Nothing changes when I execute it a second and third time; the button remains disabled.

When I return to 'use RTICommon' and execute it, the export button changes to enabled. Nothing changes when I execute it a second and third time; it remains enabled.

From what I can see, RTICommon is accounted for in the fully qualified Select statement. The other two domains are not in the script, at all.


use RTICommon;
use rticommunication;
use rticompany;
select * from RTICommon.dbo.tbLog
CreateDate > dateadd(MINUTE,-180,getdate())
and message like 'IFR QueueFuelAndRouteRequest%'
order by createdate desc;

To the previous SQL I added a fully qualified Select statement that uses RTICommunication. When I execute the Select statement, the button enables. And then when I follow the procedure in the previous message, the results are the exact same.

So, it appears to be something related to the first 'use' statement in the SQL.

All who are having problems, try fully qualifying the query that generates the results and see if that changes the behavior of the dump/export buttons.

-- SQL01 - Alter tbPosition data:
FROM RTICommunication.dbo.tbPosition pos
WHERE pos.datetime > dateadd(MINUTE, -90, getdate());

Same here. Seemed to happen after updating to 2017.2, and opening a new console fixes it temporarily. Please fix!


I am also experiencing total loss of export tools. Also next page / load more controls in the data view windows are disabled.

First noticed this issue with 2017.2.



I'm on 2017.2.1 (MSSQL) and this problem has been bothering me for a while. I just figured something out: if you execute any query that doesn't begin with a result set the Data Dump for any output is disabled.

For instance if you print a line or declare a variable as the first statement or change the database, the output is disabled. You can simply add a query at the beginning of the executing to return data from a table and it will enable data dump on all subsequent results.

I'm guessing that the programming is setting some flag saying that the result isn't able to be dumped because it's not a true result set. However the flag isn't getting cleared for further results.

-- Don't execute the comments
-- Can't Data Dump table Users
PRINT 'Hello'

-- Can Data Dump table User 1 & 2
PRINT 'Hello'

It may be a flag not getting cleared, but I don't think its behaving quite the way Joey said. Here's what I'm observing in version 2017.2.1, build DB-172.3757.39 on Mac, connected to SQL Server.

After restarting DataGrip, I can run my query and save to a file. If I run the exact same query a second time, export functionality is disabled. I can restart DataGrip with the same result afterward.

My query has a few DECLARE statements at the beginning for bind variables.


We may be seeing different bugs, however did you try adding a query to the top above the DECLARE statements?


Ah, yes. That workaround also fixed what I was seeing. Perhaps I will read more closely next time!


Please sign in to leave a comment.