Read Only issues with Auto-Commit

EDIT: When set to Auto, it now tells me when I attempt to edit a cell: "This table is read only. Search path mismatch"

First attempt at a query and subsequent edit after a DataGrip re-start works just fine with AutoCommit on. Any queries and attempts at an edit after requires a restart, over and over. 

This is just flat-out unusable. 

Hi,

Could you describe your steps to reproduce, define database you use?

Thank you.

SQL Server 2012

Steps:

Open DataGrip > SELECT * FROM dbo.foo (Can edit fields in table at will) > SELECT * FROM dbo.foo (Table is read-only. Search path mismatch)

I have to close and re-open DataGrip, and each time the FIRST query I run will allow me to edit. Any and all subsequent queries and an attempt at an edit result in "Table is read-only. Search path mismatch"

If I close DataGrip and re-open, same result. 

I have switched to DBeaver. 

I have the same issue with "Table is read-only. Search path mismatch" in DataGrip 2017.2.1. 

I'm using a FirebirdSQL - JDBC driver to connect to a FirebirdSQL database. This behaviour seems to have been introduced with 2017.2.1 or 2017.2 as I had no difficulty updating records in earlier versions.

This issue was resolved for me with 2017.2.2

Almost the same issue:

I am getting "Table is read-only. Unresolved table reference". I have Synchronized the DB and tried the rechecking the Read Only option multiple times.

Same problem, postgres. Just downloaded this product today & already hit this apparently insurmountable bug. The SO question on this issue is over 2 yrs old and it's apparently still a problem. Would be great to see a response from JB. 

@brandonmp Hi,
Could you define steps to reproduce your problem by providing your data source settings and test query?
Thank you.

@Anton 
I had the same issue with "Table is read-only. Unresolved table reference". I noticed that one of the columns in my select query is yellow colored because the column was added by another developer and I have not synchronized table after that. Although that I could see query result in console I couldn't edit it. The problem was solved by synchronization of the table.

@ Edvard Davtyan 
One can edit query result set only for simple queries. 

@vasily_chernov
What do you consider as "simple query"? About all the queries that I use is available for editing.

If it is a  simple select statement then you can edit result set.

Hmmz I think this is related to the edit window...

If I use this field to write my where clause it works:

Because the results are shown in the main window.

However if I execute the following(which is the same) query from the Scratch file:

SELECT * FROM CasinoMappings WHERE casinoName LIKE '%playtech%';

The result are shown in the Result Window and are NOT editable!

@Anton

Yes, you're right. Actually, grid editor and result set editor is different functionality. For now, result set editor can be edit only for simple select statements.

There are some issues you can track:

• https://youtrack.jetbrains.com/issue/DBE-5278
• https://youtrack.jetbrains.com/issue/DBE-720

This has been an on-going problem for years and it still is not resolved as of version 2021.2.3. The grid editor for result sets has an intermittent problem where it will not allow the editing of a field unless the schema name is explicitly referenced in the query. The error is "Table is read-only. Unresolved table reference." Even the simplest of queries will experience the problem. An example is "select * from contacts". Doesn't get much simpler than that.

Steps to repeat: run a query, try to edit a field in the results, experience error message, search online for a resolution, trudge through the forums here to see if anybody has fixed it yet, repeat.

All of the tips and workarounds found here and elsewhere (e.g. StackOverflow) do not fix the issue. This includes:

• toggling auto-commit and transaction modes
• confirming that the connection is not read-only
• refreshing the schema
• restarting DataGrip
• re-creating the data source profile
• re-installing DataGrip.

The ONLY thing that works with any measurable success is explicitly specifying the schema name in the query. However, that is very inconvenient for those of us that have to work with multiple databases whose schemas have different names.

One noticeable characteristic is that this does not seem to happen on other schemas in the same database. There is no difference in permissions between the two schemas and even accessing them as root results in the error. Again, explicitly specifying the schema name does not experience the error, only if the schema name is omitted.

The editor clearly knows which schema to use based on what is selected in the schema dropdown in the upper right corner because queries work without needing to have the schema explicitly specified.

The two issues that were referenced above by Vasily are completely unrelated to this issue.

Please, JetBrains, fix this.

Dave Young,

So, let's file a new issue then? Could you also attach IDE and SQL logs it would help us to investigate your problem.