SQL vs Command windows

[Joan Lawson]

I have a long series of sql commands that I run manually on a daily basis while still needing to prove that all is working as designed.

Each command does an insert or update and is followed by a commit. On occasion, the command will return a "executing...", and not complete. I do a break. And, still cannot get the command to complete. (The command can be as simple as an update to one row).

If another person executes the same exact command on the same database in a different session, in a command window, it works perfectly fine. She says that it is safer/better to run these commands in command windows rather than in sql windows.

Any thoughts on this - what could be wrong on my part - or whether there is a difference between the sql and command windows? Any thoughts would be appreciated.

Thanks.

 

[William Robertson]

One difference that comes to mind is that the SQL window does not require a SQL*Plus-style semicolon or slash to terminate each command, while the Command window (being a SQL*Plus emulator) does. Could it be hanging at the prompt waiting for a slash or semicolon?

If not, what is the session waiting on?

In the Sessions monitor, I have a custom table named "Current Wait" defined as:

SELECT wait_time
     , seconds_in_wait, wait_class
     , state
     , event
FROM   v$session_wait
WHERE sid = :sid
ORDER BY seq#

 

[Marco Kalter]

If the command does not complete, there may be a lock situation. Perhaps you can verify this?

 

[Joan Lawson]

To respond to William - the semicolon is there, and I do get the 'executing'.
Marco - I would agree; but, the dba says she does not see a lock - and when she executes the same command (a delete of one row in a table), it completes. And, I do have all necessary privileges, and executed similar commands on the same db objects before and after.

 

[William Robertson]

So, what is the session waiting on if not a lock?

 

[pwo1433]

William,
your code may be helpful to me.
Where do I find my 'sid' ?
Thanks.
Paul