1.5.3, 3 possible bugs, incorrect information and patchy functionality

Question

on windows XP SQL Dev 1.5.3
1.) From the tree structure, I filter Other Users, then open another users views folder. Click on the view that I want to see information for, and instead of the 7 columns that the view is actually composed of, it lists it's 7 columns 3 times for a total of 21 columns.
2.) When trying to edit a procedure I've noticed that there is typically a +/- sign to expand and collapse loops and begin/end structures. It seems like it's hit or miss whether or not you get this functionality to work.
3.) I issued the following select and got unexpected results
select col1, col2, col3, table1.*
from table1;
this should return col1, col2, col3, col1, col2, col3, col4, col5, etc... with the values from col1 - col3 being the same in each row, well on several rows I noticed the values didn't match.
I'm beginning to get very wary of using SQL Developer to do anything other than just query data. I'm sort of afraid to use to actually make any changes within the database for fear of incorrect DDL being issued back to the database and corrupting something.

Answer 1

Firstly, have you had a chance to test the problems on 1.5.4? The new release has certainly included some bug fixes.
As for your issues:
1) Which DB version are you connecting to? Do you get 7 or 21 columns listed if you just expand the view node instead of opening the view object tab?
I am on 1.5.4 (connecting to 10.2.0.3) and only get each column once when opening the view object tab for a view owned by another schema. Tracing SQL Developer it is using the following query to get the columns:
select c.column_name,
         decode(data_type,'CHAR'    ,data_type||'('||c.data_length||')',
                          'VARCHAR' ,data_type||'('||c.data_length||')',
                          'VARCHAR2',data_type||'('||c.data_length||')'    ,
                          'NCHAR'   ,data_type||'('||c.data_length||')'    ,
                  'NUMBER'  ,decode(c.data_precision,null,'NUMBER', data_type||'('||c.data_precision||','||c.data_SCALE||')'),
                  'NVARCHAR'  ,data_type||'('||c.data_length||')'    ,
                          'NVARCHAR2' ,data_type||'('||c.data_length||')'    ,
                          data_type) data_type,
            decode(nullable,'Y','Yes','No') nullable,
            c.DATA_DEFAULT,
            column_id,
            com.comments,
                        c_update.insertable,
            c_update.updatable,
            c_update.deletable
      from sys.all_tab_Columns c,
           sys.all_col_comments com,
           sys.all_updatable_columns c_update
      where c.owner      = :OBJECT_OWNER
      and   c.table_name =  :OBJECT_NAME
      and   c.table_name = com.table_name
      and   c.owner = com.owner
      and   c.column_name = com.column_name
      and c_update.column_name = com.column_name
      and c_update.table_name = com.table_name
      and c_update.owner = com.owner 2) I tried the same thing (once again on 1.5.4, but have not noticed this on 1.5.3 previously), although my package didn't have for loops, but did have standard loops and while loops. There was a very slight delay before the expand/collapse options appeared, but they appeared both times after the same short delay. With very large package bodies there can be a much more noticeable delay, but from the size of your scroll bar in your screen shots, it looks as though my test package which only had a slight delay is already longer than yours.
3) I wasn't able to reproduce this either
theFurryOne