This discussion is archived
9 Replies Latest reply: Jul 18, 2012 12:28 AM by archimede RSS

Serious SQL Developer bugs

xxsawer Explorer
Currently Being Moderated
Guys I just found pretty serious bug in SQL Developer. I cannot imagine, how is this possible...

It's simple. Open two connections (lets call them connection A and connection B) and open a file from disk containing some package specification or body.
The file is immediately assigned to a connection. To which one??? How SQL Developer determines to which connection assign a file when you have 10 connection opened???

Ok, lets say, the file was assigned to connection A, but you wanted to assign it to connection B. You didn't notice it is assigned to connection A and compiled it. Because it should be compiled to connection B, you may get some errors.
Now you realized you made a mistake and swich the connection to connection B in the right top corner. Compile again...and nothing... The package is still being compiled to connection A. How can this happen???
But this is not the worst, this is just beginning...

SQL Developer is remembering which file was compiled to which user and is even cashing the password somewhere!!!
So consider this...
Open a package from disk, compile it to some connection (lets call it connection C). Now connect to another server (lets call this user D - it has different username than user C) which unfortunately has the same user present and other connection details as user C on previous server.
Open the same package and what happens? A window jumps on asking for password to user C? WTF??? Why is SQL Developer remembering where was the file last opened, compiled or whatever??? Ok, so you click Cancel (you have to do it several times because Developer probably doesn't understand what Cancel means and asks for password again and again). Finally you open the file and check if it is assigned under user D. It is, perfect, lets compile it. What happens? Developer compiled the file to different user!!!!
It compiled the file to correct server, but used the cached connection details from connection C and compiled it there!!!

I don't know how company like Oracle can even sign under such product.
This software is not only unusable and buggy as hell, it is also dangerous and you should not only stop distributing it but also inform current users about it.

Dan
  • 1. Re: Serious SQL Developer bugs
    PaoloM Newbie
    Currently Being Moderated
    Dan,
    which SQL Developer version shows this weird behaviour?
    How did you define your database connections? (basic, TNS, etc.)
    Which database version?

    Thanks,
    Paolo
  • 2. Re: Serious SQL Developer bugs
    Jim Smith Expert
    Currently Being Moderated
    Surprisingly, I have been able to reproduce this in 3.1.07.42.

    I'll put together a test case later, but in summary.

    1 Create two basic connections - same database, different schemas.
    2 Create a file testpackage.pkg which creates a simple package.
    3 Open the file.
    The file is immediately assigned to a connection. This seems to me to be changed behaviour as it always used to be the case that you had to manually select the connection for newly opened files. I tried this a few times with different files and it seems to be arbitrary which connection is assigned.
    4. Compile the package, and check that it appears in the object browser for the assigned connection.
    5. Change the connection drop down to the other connection.
    6. Compile the package.
    I got an insufficient privilege error. This implied it was trying to create the package in the original schema. To test this, I granted the second schema create any procedure privilege and changed the name of the package. Compiling now creates the new package in the original schema.

    Not good. I haven't tested the stickiness of connection to file the OP complained of, but this error is bad enough.
    I haven't come across it before because it doesn't match the way I work, but I'm surprised no-one else has.
  • 3. Re: Serious SQL Developer bugs
    xxsawer Explorer
    Currently Being Moderated
    To PaoloM:

    I am using the latest version of SQL Developer of course.
    Connections are defined normally in SQL Developer, database version is irelevant...

    To Jim Smith:

    Jim, I am not surprised nobody submited this bug before. I knew about the first part of this bug since this version was released and I am pretty sure there is planty of users which know about it.
    I just have no time and energy to submit everything I find, moreover I know it is useless. The latest version of Developer introduced so many bugs, you wouldn't believe. In combination with all those old bugs (often very basic ones) it's disaster.
    This could be acceptable if this would be developed by enthusiastics in version 0.001 alfa and not shiped with database server.
    Check my threads and find how many bugs submited only by me are fixed. Almost none.
  • 4. Re: Serious SQL Developer bugs
    archimede Newbie
    Currently Being Moderated
    xxsawer wrote:
    I just have no time and energy to submit everything I find, moreover I know it is useless. The latest version of Developer introduced so many bugs, you wouldn't believe. In combination with all those old bugs (often very basic ones) it's disaster.
    I couldn't agree more, sadly.

    I stopped using SQLDeveloper with more than ONE connection open a long time ago. :(

    Alessandro
  • 5. Re: Serious SQL Developer bugs
    Jim Smith Expert
    Currently Being Moderated
    I am seeing the same behaviour in 3.0.03.97
  • 6. Re: Serious SQL Developer bugs
    Jim Smith Expert
    Currently Being Moderated
    The second part of your post may be connected to the "Link Stored Procedures to Files" preference (Tools|Preferences|Code Editor). It seems to be on be default and it looks as if it may cause the behaviour you are seeing.
  • 7. Re: Serious SQL Developer bugs
    rp0428 Guru
    Currently Being Moderated
    >
    I am using the latest version of SQL Developer of course.
    Connections are defined normally in SQL Developer, database version is irelevant...
    >
    Saying things like 'latest version', 'defined normally' and 'database version is ireelevant' are useless to anyone that want to try to help you.

    When someone asks for information please provide it. For version, don't just say 'latest version' but provide the full actual version.

    For connections 'defined normally' doesn't provide enough information for someone to try to reproduce your exact problem. What is 'normal' can depend on preferences or other settings and we want to use YOUR settings without assuming that we know what they are.

    And 'database version is irelevant' is an opinion unless you have actually tested the issue with multiple database versions. Again, that is likely an assumption on your part rather than a fact.

    In order for people to try to reproduce the problem they need facts, not opinions. It can waste a lot of time trying things in a way, or on a version, that really isn't the same as the versions of things that you are using.

    The user asking you those questions was really trying to help you despite your rantings about the product. If you want help you have to help those that ask try to help you.
  • 8. Re: Serious SQL Developer bugs
    xxsawer Explorer
    Currently Being Moderated
    To rp0428:
    Guys...without any personal hate to anybody here, I have to say this:
    I think it's exactly the other way. In fact you are not trying to help me, I am trying to help you. You would be trying to help me if I would ask if some feature is present, how to do something and so on...
    I am reporting your bugs! Beside this bug, I mentioned here many others and still nothing happened.

    I think it's more than clear this is pure SQL Developer bug and has nothing to do with server and I bet also with connections to the server.

    Anyway to have this complete, I am using
    Developer Version 3.1.07 Build MAIN-07.42
    Database server where this happened is 11g, but in general I have about 100 connections defined to different servers and schemas from version 8something to 11g
    Connections are defined within SQL Developer

    I think it is also good to notice that the user where the package was compiled even isn't in my connection list. I even didn't know where the package was really compiled, so I had to find it through ALL_OBJECTS view!!!
    Developer is probably selecting from ALL_USERS and trying to find that user to which this package was compiled last time and because that user was present and had all connection details the same, it was compiled there - unbelievable.
    If this would be a production server, it would stop the production because of invalid packages...

    What I also don't understand is why you already didn't check the sources? For me it's pretty time consuming to test exactly how something happens. You have all the sources can find it quickly.
    BTW. I already reported one similar bug regarding that Open Declaration feature in previous versions and of course no answer. This bug caused that when you used Open Declaration it could open a package from completely different schema maybe even server. If you didn't notice this (which is pretty hard because the package name was correct and schema name isn't displayed anywhere) you could compile a package from different scheme to current scheme. Wow...

    This is also reply for Archimede... I had only one connection opened when this happened, so this won't help.

    Jim Smith:
    I don't know what this feature does. I checked the help quickly and it's not there, cool...
  • 9. Re: Serious SQL Developer bugs
    archimede Newbie
    Currently Being Moderated
    xxsawer wrote:
    This is also reply for Archimede... I had only one connection opened when this happened, so this won't help.
    What you describe never happened to me. I was mainly referring to Jim Smith's reply (post #3 above).

    Regards.

    Alessandro

Legend

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