I have a PL/SQL package in SchemaA.pkg_a, defining some global subtypes, types and modules (cursors, procedures, functions, etc.), and a package in SchemaB.pkg_b, that uses items from from SchemaA.pkg_a, and declares others of its own. Usual implementation.
Now, package SchemaA.pkg_a calls one procedure from SchemaB.pkg_b, so they become "interdependent" (A references B, while B references A). I compiled them the usual way (for this, "interdependence" situation), first the specifications, then the bodies.
I added debugging info for both packages (again, for specifications and bodies) and granted execute and debug privileges on SchemaB.pkg_b to SchemaA. I used to be able to debug SchemaA.pkg_a, and from it, stepping into SchemaB.pkg_b without any issues. After some extensive changes (lots of additional code) to both packages, SQL Developer stopped stepping into SchemaB.pkg_b body. It does step into its specification (some constants declaration).
I debug the same packages using PL/SQL Developer (from Allroundautomations), which does step into SchemaB.pkg_b body, so I tend to isolate the issue to SQL Developer (not packages).
I need to debug in SQL Developer, since the packages are using a ton of multi-dimensional collections, and no other tool (that I know) allows drilling deep down into variables of such types.
Any ideas?
Unfortunately, I have no code (that I could share) to reproduce the issue.
Note: Both packages use declarations of subtypes, record types, PL/SQL tables (collections) indexed by binary_integer or by varchar2, cursors and subtypes as cursor%rowtype, some collections use those subtypes as their record types. Some functions/procedures use "in out nocopy" parameters.