This content has been marked as final. Show 8 replies
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  in the next release.
SQL Developer Team
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.
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...
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.
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.
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.
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?
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.