This discussion is archived
8 Replies Latest reply: Oct 27, 2012 10:11 AM by Gary Graham RSS

SQL Developer: infuriatingly unstable

968842 Newbie
Currently Being Moderated
How many times should a person need to force-quit an application each day due to bugs?

The connection handling in SQL Developer is atrocious. If a session drops out due to inactivity or a network issue, it's not uncommon to get stuck in a "Do you want to reconnect? Abort, Retry" loop that can only be ended by force-quitting the application.

Attempting to quit the application after a connection has been dropped or timed-put often results in the same frustrating loop, that can only be stopped by killing the application.

Often, a worksheet for a connection will be working just fine, but using the schema browser will tell you that there is no connection, and do you want to reconnect. Whilst at the same time, the worksheet continues working just fine.

Often, when a connection is lost, the "reconnect" option in the context menu is disabled, and the only option is to "disconnect", which attempts to do so gracefully, to a connection that doesn't exist, meaning you get the "Do you want to reconnect" loop, or have to wait for an arbitrary period of time until it realises it's no longer connected. Often the "reconnect" option will remain disabled weven when SQL Developer has told you that a connection has been lost.

These bugs have been present for as long as I can remember, right up until 3.2.1
  • 1. Re: SQL Developer: infuriatingly unstable
    Gary Graham Expert
    Currently Being Moderated
    Hi,

    Thanks for posting -- I believe yours is the first comment regarding Reconnect on this forum for 3.2.x.

    There are a couple of issues we are trying to address in order to make Disconnect / Reconnect stable:

    1. The test for enabling Reconnect in the context menu can be blocked by a background thread pinging the DB. This is the primary cause of your complaint. If the network connection is dead, waiting for a timeout can take some time. Other failures like database session killed or timed out, or database shutdown will not experience such long waits.

    2. After losing a database connection, some UI components that cache their own copy of the connection name somehow have it NULLed out and a subsequent Reconnect does not update it. Fortunately most components check for connection name in one common location. The object viewer Data tab, however, suffers from this caching problem. An attempt to refresh an open Data tab after a Reconnect was failing due to the NULL connection name. As a workaround for 3.2.x, the user is presented with a dialog that recommends closing / reopening the object viewer, but provides the option of selecting a connection name from the Connection Selector UI so the refresh may proceed.

    We hope to address point [1] in the next release.

    Regards,
    Gary
    SQL Developer Team
  • 2. Re: SQL Developer: infuriatingly unstable
    968842 Newbie
    Currently Being Moderated
    Thanks Gary,

    Thanks for taking the time to answer. Sounds like a very complex internal architecture. I would rather have stable connection handling than most of the other features of SQL Developer.

    Today's issue: open a package body to edit, attempt to compile it. Receive a "No more data to read from socket" error. Click "Disconnect" on the connection in the browser. Lose the work in the editor, which is automatically closed on disconnection by default. reconnect, confirm connection is working by issuing a query in a worksheet, repeat with same result ad infitum.

    Restarting SQL developer resolves the issue.

    I've gotten into the habbit of restarting SQL Developer every couple of hours in order to maintain some type of stability.
  • 3. Re: SQL Developer: infuriatingly unstable
    xxsawer Explorer
    Currently Being Moderated
    Hi user6771696
    I agree with you that the Developer is unstable and buggy as hell, but I also think you are doing something wrong.
    Why are you editing something directly in the database? Generally you should never do this. You should have sources checked out somewhere your system, edit those sources, compile them to proper connection and then commit them to SVN.
    Changing anything directly in the database is not good. Anybody else can rewrite our changes and nobody will find out why and who...
  • 4. Re: SQL Developer: infuriatingly unstable
    Gary Graham Expert
    Currently Being Moderated
    Today's issue: open a package body to edit, attempt to compile it. Receive a "No more data to read from socket" error. Click "Disconnect" on the connection in the browser.
    This is fixed in the next release. When you learn your VPN connection is lost, reconnect it, then use the Reconnect option rather than Disconnect from your connection node.
    Why are you editing something directly in the database?
    Using a source control management system is always a good idea. Even so, everyone wants this tool to be rock solid -- the next release should be much better.

    -Gary
  • 5. Re: SQL Developer: infuriatingly unstable
    B.Delmée Explorer
    Currently Being Moderated
    the next release should be much better.
    Thanks for teasing us, Gary, but are you referring to 3.3 or hopefully some sooner released revision (perhaps 3.2.2) specifically addresssing the long-standing connection stability issues? I wouln't call sqldev buggy as hell but its behaviour in the face of a lost link has been the number one annoyance for me. I believe there have been plenty of posts about it, too. It may not affect that many users, but those with unstable connections do feel the pain. Not really oracle nor sqldev's fault, but some have to deal with poor connectivity and ideally this should be handled gracefully.
  • 6. Re: SQL Developer: infuriatingly unstable
    Gary Graham Expert
    Currently Being Moderated
    are you referring to 3.3 or hopefully some sooner released revision (perhaps 3.2.2)
    Standard policy here is to say only that a fix or enhancement is in the "next" release or patch. Sometimes we slip and give the number. In this case, expect the fix sooner rather than later. As always, watch for an announcement in this forum.

    The original iteration of Reconnect would have been more successful if testing had simulated a dropped VPN connection properly. Initially we tested only scenarios like killing the database session, stopping the database, pausing the VM running the database, physically disconnecting the client machine from the network, and logically disconnecting the VPN client (Disconnect menu option) from the network. It turns out a more realistic simulation of dropping a VPN connection is to put the client machine through a sleep/wake cycle.

    -Gary
  • 7. Re: SQL Developer: infuriatingly unstable
    xxsawer Explorer
    Currently Being Moderated
    Hi Gary,
    basicaly there are two reasons why not to use version control system included in the Developer.
    1) As you mentioned this feature must be rock solid. Simply there cannot be any bug in it. Considering the state of the Developer, I don't trust this feature. To make any sence of it, it also has to provide all SVN features. I think this principaly cannot be done. Storing "code" to svn doesn't mean storing onle the packages, you have to store everything related to your project. Table definitions, views, grants, ..... and I want to store it exactly like I programed it. Is this possible? I don't think so.

    2) As I already mentioned, it is principle wrong to edit anything directly in the database. The sources should be checked out somewhere on the disk and these are the sources you should edit! When you are programing something you probably don't want to compile the sources to the database whenever you save the "file", right?
  • 8. Re: SQL Developer: infuriatingly unstable
    Gary Graham Expert
    Currently Being Moderated
    Hi Dan,

    I don't want to get too far off the original topic of stability with regard to the Reconnect feature, but I will say...

    1) SVN support in SQL Developer is dependent on what we inherit from JDeveloper. We don't do anything extra at this time.
    2) Source control management is a good thing. I can imagine a developer prototyping/doing RAD, but eventually code management is a must.

    -Gary

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points