Debug across schema

[jhughes]

I'm struggling to find the correct combination to allow user A to debug through code it owns that also calls a package owned by user B. I need to debug through the logic owned by B but it is only called via A after some setup is done in the A owned logic.

All packages for user B are compiled with debug logic (confirmed via DBA_PLSQL_OBJECT_SETTINGS)
User A has DEBUG CONNECT SESSION and DEBUG ANY PROCEDURE.
User A can view the source code for User B (I can do a do a View Spec & Body and the code opens up).
PSD is set to "Use DBA Views if available"
I have a breakpoint compiled into the code via User B.

Thoughts on what I'm missing?

 

[Marco Kalter]

Can you check if you have select privileges on the SYS.DBA_OBJECTS and SYS.DBA_SOURCE views?

 

[jhughes]

The user does, though it is via a role.

 

[Marco Kalter]

That should be sufficient. Can you check if you can step into any procedure or function owned by User B, instead of using a breakpoint?

 

[jhughes]

I setup a simple case and debugged through code in User A and continued debugging code in User B when the User A code called a package owned by User B. This verified the basic debugging concept works when starting in User A and debugging through code owned by User B.

Where it falls apart (and what I forgot), is that we have an EXECUTE IMMEDIATE in the chain of getting from our generic driver processing to message specific processing. This concept was built back in the early 2000's. If the EXECUTE IMMEDIATE calls code owned by User A, the debugger continues to step through the called code owned by User A.

When that code called by EXECUTE IMMEDIATE is owned by user B, the debugger no longer can step through it. Not sure why the difference there.

 

[Marco Kalter]

That may indeed be the cause. We'll investigate.