DataGrip 2018.2.4 is Here

When it comes to the tools of your craft, it never hurts to make sure that you are always working with the most stable version. Please meet DataGrip 2018.2.4. Inside you’ll find the following have all been fixed:

  • DBE-7023 The Find Action not working when invoked from the Welcome Screen
  • DBE-7019 The JSON exported data being formatted to scientific notation instead of flat
  • DBE-7012 The import of a custom enum type to PostgreSQL from CSV not working
  • DBE-6996 The ClickHouse datasource not properly loading after an IDE restart
  • DBE-7007 The MySQL dialect configuration change which was lost after every IDE restart
  • DBE-6939 The delayed preview of changes in the Code Style settings

That’s mostly it. Again, if you find a bug, make sure to let us know. We’ll do our best to include a fix in an upcoming update. Enjoy!

The JetBrains Team
“The Drive to Develop”

This entry was posted in Releases and tagged , . Bookmark the permalink.

19 Responses to DataGrip 2018.2.4 is Here

  1. Rolando Urrea says:


    When generating a DDL from a Postgres table or database, the “timestamp without time zone” field is not correct; it only generates a “timestamp” definition.


  2. bruce tang says:

    will you add function to export excel ? The existing export function is very bad.

  3. Dean says:

    Still waiting eagerly for to be released, in a hope it will resolve needing to restart datagrip every hour or two.

  4. Mark Jackson says:

    Requests for Exasol:
    1. Recognize IFNULL() as a valid function
    2. Allow for brackets as field / schema qualifiers.
    3. Syntax highlighting for Lua / Python scripts. Currently it just colors the whole block in green.
    4. Import data from CSV using the import from CSV DML statement. Last I checked, Data Grip writes row-by-row insert statements, which is incredibly slow.

    I’m very happy with the product though. Just have a few quirks working with Exasol.

  5. Chang Liu says:

    Will you consider supporting tidb what is a distrubuted sql database?

  6. Aaron says:

    When will I be able to update and it not overwrite the formatting I had previous to version 2018.2? I’m all for updating code formatting but when I upgrade and the options don’t let me get back to how I previously had them setup it’s rather frustrating.

  7. Taylor says:

    I noticed today when trying to run a .sql file on my mySQL DB that changes to a .sql file don’t immediately get picked up by DataGrip. I’ll run the .sql, hit some error, make changes to the file, and then try running again, but the edits I’d made and saved are not seen by DG. DG is still reading the old version of the .sql file, the one with the error in it; I can see the old lines of code in the error report. I’m waiting 5-10 minutes for the changes to get recognized.

    I have little experience with database software, so sorry if this is obvious, but is this a bug or a setting? To get around it, I duplicate my .sql file and run it instead until the original file’s changes are recognized in DG. Thanks!

    • Maksim Sobolevskiy says:

      It’s not very clear. Usually we save EVERYTHING you do with files. Can you record a screencast? Or even provide a screenshot.

      • Taylor says:

        To clarify, I’m not working on this .sql file on DataGrip. I’m writing it in a simple text editor, saving it, and then running it against my database on DataGrip with your new Run SQL Script… option. When I make changes to my .sql file in the text editor, save, then try to Run SQL Script… again, DataGrip doesn’t see the changes I’d just made to my file.

        • Maksim Sobolevskiy says:

          Can you please describe why you write queries in third-party editor?

          • Taylor says:

            I didn’t think it mattered whether I wrote .sql files in vim or in TextEdit or in DataGrip, so I wrote it in TextEdit. Arbitrary choice. Just a minute ago, I tried editing my queries in DataGrip instead and am not running into the same issue. Thanks for the hint!

            Still, it’s odd that DataGrip isn’t seeing changes made to queries by a third-party text editor.

  8. Julius Simon says:

    When updating a procedure or function I always have to add a semi colon at the end of my procedure before the final “/” character. If not, the package, procedure or function gets reported as invalid because a semi colon that I have in my code has been omitted.

Leave a Reply

Your email address will not be published. Required fields are marked *