The session browser shares your worksheet connection. So if you have a long running query, it will always block the session browser, as well as running reports or clicking around in the navigator tree.
However, if you open an unshared worksheet for your long running queries, you should be good to go with the rest of the application.
When you cancel a query, we send the request to the database. At that point, it's out of our hands. If anything, query cancellation should be BETTER in 17.3. If you're experience is otherwise, then the the best solution is generally to setup thick connections (use an oracle client) in SQL Developer.
Thank your for your quick answer.
As a default I use unshared connection, so maybe I am doing something different wrong. The picture shows German language but I guess the position should be the same, I guess.
In the 1st worksheet I run my query. I open now a second worksheet, and I think due to the settings it should be unshared, right? After the 2nd worksheet appears I try to open the session monitor. The session Monitor will only appear after the query has finished.
Regarding the query cancellation, I understand that you have for wait until the database answers. But somehow it takes too long until the query aborts. I 've tried it with thick (12.1) and thin connection with no difference, but so I have to live with the cancellation from a second SQL developer.
1 person found this helpful
the option to default to unshared connections applies to when you open a 2nd worksheet. the first one that opens by default on a connect still defaults to the shared behavior.