Toad World® Forums

Debug sys schema procedure


Toad x64 on Oracle
connected as named user with sysdba privilege.

created one procedure and turn on debug feature.

Start debug but in window I do not see proc parameters.

Is this normal or a bug?



Bug. Most likely user views are being used. I see similar behavior in the Load from DB window. Even when my schema is chosen objects owned by SYS are shown. I’ll take a look.


There is a bug there in Load from DB; however, in your case there is no bug in my opinion.

When you create the object without the schema specifier then it is owned by SYS if you connect as SYSDBA. If you intended for it to be owned by the named user you need to fully qualify the object name to include the owner. When object DDL exists in the Editor without the owner present it is assumed to be owned by the connected user. The query to populate the arguments is searching for that object owned by the named user, not by SYS.


Hm ok if you say so.
When you run debugger from Toad editor there is no way that I pass anything to that.

I know it is not 100% professional, but seems that debugging SYS code while connected as sys is not possible in that way?

I’m looking at it now, but I’ll need to see how much code requires changed before committing to anything this late in the release cycle. I’ll log this at any rate… there’s room for some improvement. A brief search shows multiple places where changes are required.

  1. The Current Schema dropdown in Editor.
  2. When to add schema name based on the “Object loading” option mentioned below (this option is used outside of Editor as well).
  3. What to do about freshly typed DDL that doesn’t include owner.

debugging SYS code while connected as sys is not possible in that way

It is, you just have to work with the current limitation and add SYS.object_name in your DDL when you want to execute. There’s also the “Object loading” options on the Editor|Open/Save page have 3 possible values, use “Always include” or “Include on loads from other schemas” and that should cover you when loading objects from SB, PM, etc.


I’ve made all of the changes I could locate. Surprisingly there were quite a few “ALTER SESSION SET current_schema” calls that were not properly handling anything other than normal connections.

Everything looks good now for loading objects, executing, etc., but my earlier workaround may not work for you, after all. Even logged in directly as SYS I cannot debug SYS owned objects. SYS has all necessary privs and the object was compiled with debug so I don’t know what’s up there. This beyond both my DBA and DBMS debugger expertise. Someone else will need to step in, but next beta will have my work in it.


Back in the dark ages (Toad 9.x I think), we had an option to step into sys/system procs. Since it was almost a decade ago, I’m a little fuzzy as to why we removed that option but there is a possibility that there was a good reason for it. Of course, it could have been for a terrible reason as well. In any case, I think there’s some setting down in the bowels of the debugger code that is turning this off and even though it’s a named user, the debugger is still seeing them as SYS/SYSTEM owned procs. That’s my current theory and it’s subject to change as new evidence is discovered.

Hi Gregory, Micheal,

I see that this makes a huge amount of problems. While you do not fix that maybe just to place some message or warning while starting debugger in SYS session. This could be more “friendly” to customers that are not not so experienced (and all of them are mostly in SYS session, believe me).