Issues that makes DataGrip an odd tool I can't recommend as a database development tool.

Hi Team,

Issues that makes DataGrip an odd tool I can't recommend for daily use as database development tool.

IF you know that I missed some option or setting that could help to resolve any of the below issues - please let me know. IF I do something in a wrong way, please let me know the right way please.

1. There's no value alignment in result set dependent on column data type. This is a basic way a database tool should work with result set. Without it the tool is useless IF you work a lot with data. https://youtrack.jetbrains.com/issue/DBE-2701 (Created on May, 2016)

2. There's no way to simplify database connection management in case you have more than a few connections. Have you ever worked with Oracle database? Each user/schema has it's own password, a database may have a lot of different users/schemes in scope of the same application. Plus DEV, QAT, UAT, PROD environments. And we have more than 20-50 connections in scope of the same project. It's a madness. A simple grouping could make things looks better. Should I create a separate project for each environment looking on the same repository folder? probably this will be more ridiculous.

3. DataGrip has issue with autocomplete. For Oracle source code:

• DataGrip knows nothing about, as an example, ALL_SOURCE view even IF I set on all schemas in Options tab of connection properties.
• IF I have two connections to the same schema on different database environments (DEV, and QAT) - autocomplete will suggest BOTH (!) tables.
• In case of a bit complex SQL query with WITH clause - DataGrip fails to parse it.
• Actually, a lot of 'Unable to resolve ...' issues with Oracle source code. Sometimes it looks like 70% of the package is unresolved. As an example, a constant from package specification is not recognized in another package body (sic!).
• DataGrip does not know about COLUMN_VALUE field of Oracle object type, as an example, AS TABLE OF NUMBER...

4. DataGrip logic of source code execution on a database is sick with f# dualism. If we are going to execute a SQL file from Files tab - we will be asked about what database we should use. Ok - it's normal and acceptable. But when we are going to run a selected SQL query within an open file - DataGrip will silently execute the SQL query on a database associated with the file previously! Yes, it will be asked only first time you run the file, and ... I'm still not sure what will be selected as a target database...

5. For PostgreSQL database I have seen issues with metadata collection. I create a foreign key. IDE uploaded incrementally the foreign key. A few actions by creating additional foreign keys - and first one is gone. Even complete metadata uploading does not help.

6. DataGrip does not know about Oracle CHAR keyword for type definitions https://youtrack.jetbrains.com/issue/DBE-2634

7. Source code style for SQL is very simple... As an example, no chance for below style. Though it's not a mission critical issue as point #1 above.

select a.column_a      a
      ,a.column_second b
  from table_sample a
  join table_test   b on b.id = a.id
 where a.column_c = 12
   and a.column_d = 'test';

At the moment DataGrip is a tool I can't trust in full.

• I should check each field data type via system views (just in case, because I don't know is it number or a text). It's great if your database has 20 tables, but if it has more? or you see the database first time and is not familiar with it?
• I should check actual objects (foreign key, constraints, etc.) related to a table manually. No guarantee metadata collected without a mistake.
• Autocomplete doesn't work as expected and a high noise of unresolved objects in source code. Sublime or Notepad have an advantage - no useless noise warnings.

Best regards,

Kostyantyn