DEV Community: Dhana

Debugging ORA-06550 / PLS-00201 in ADO.NET: A Checklist Before You Start Changing Permissions

Dhana — Mon, 07 Sep 2026 17:54:45 +0000

Enterprise applications rarely live in a single, tidy Oracle schema. It's common to have one schema owning HR-related objects and another owning a different module, with application code that needs to call across both — and that's exactly where a specific, easy-to-misdiagnose error shows up:

ORA-06550: line 1, column 7:
PLS-00201: identifier 'SCHEMA_B.PKG_SOME_PACKAGE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

The instinctive reaction is to jump straight to GRANT EXECUTE and hope it fixes things. Sometimes that is the fix — but this error can come from several different root causes that look identical from the outside, so the more reliable approach is to verify systematically before changing anything on the database side.

The Setup

An ADO.NET connection authenticates as one schema (call it Schema A). The code needs to call a package that physically lives in a different schema (Schema B):

using (OracleCommand cmd = new OracleCommand("SCHEMA_B.PKG_SOME_PACKAGE.GET_DETAILS", connection))
{
    cmd.CommandType = CommandType.StoredProcedure;
    // parameters, execute, etc.
}

On execution, Oracle throws PLS-00201: identifier ... must be declared — even though the package genuinely exists.

Why Jumping Straight to Grants Is a Mistake

This error message doesn't distinguish between several different possible causes, and blindly granting permissions wastes time when the real issue is something else entirely. Before touching grants, work through these checks in order:

1. Confirm the exact object name and owning schema.
Copy-pasted code between similar procedures is a common source of subtle mismatches — a missing schema prefix, a package name that's slightly off, or an object that was renamed since the code was last touched. Query directly to confirm:

SELECT object_name, object_type, status
FROM all_objects
WHERE owner = 'SCHEMA_B'
AND object_name LIKE '%SOME_PACKAGE%';

Don't rely on memory or an old script for the exact name — verify it fresh, every time this error appears.

2. Check the object's status, not just its existence.
An object can technically exist but be in an INVALID state (often after a dependent object changes). The query above includes status for exactly this reason — an invalid package can throw errors that look like an access problem but are actually a compilation problem upstream.

3. Verify the parameters being passed match the procedure's actual signature.
A mismatch in parameter count, order, or data type can sometimes surface as a resolution error rather than a clear "wrong parameters" message, especially with overloaded procedures inside a package. Double-check the package specification for the exact parameter list and types before assuming the problem is schema-related at all.

4. Only now, check execute privileges.
If the name is confirmed correct, the object is valid, and parameters match — then it's genuinely a privilege issue:

GRANT EXECUTE ON PKG_SOME_PACKAGE TO SCHEMA_A_USER;

Without this grant, the calling schema's session cannot resolve the package, regardless of how correctly the call is written.

5. Consider a synonym for cleaner long-term calls.
A grant alone lets the call work with a fully-qualified name, but a synonym in the calling schema avoids hardcoding the cross-schema prefix everywhere in application code:

CREATE SYNONYM PKG_SOME_PACKAGE FOR SCHEMA_B.PKG_SOME_PACKAGE;

This also makes future changes easier — if the object's location ever changes, only the synonym needs updating, not every call site in the codebase.

Why This Combination Trips Up Developers

The error message doesn't tell you which of several possible causes you're dealing with, so it's tempting to guess rather than verify
Multi-schema Oracle setups are common in enterprise systems, but many developers' daily experience is single-schema, making this class of error unfamiliar
Under time pressure, it's easy to skip straight to "just grant it" without confirming the actual object, its status, or the parameters being sent — sometimes fixing the wrong thing while the real cause goes unnoticed

Takeaway

When you hit PLS-00201 across schemas in an ADO.NET + Oracle setup, resist the urge to immediately change permissions. Work through it as a checklist: confirm the exact object name and schema, check that the object is valid (not just present), verify the parameters match the procedure's actual signature, and only then move to grants and synonyms. This order matters — it's faster overall than guessing, and it avoids the situation where a grant gets added that was never actually the problem, while the real cause stays hidden.

In multi-schema enterprise applications, this kind of methodical, don't-skip-steps debugging saves real time compared to reactive permission changes.

The ASP.NET Session Mistake That Broke Our Multi-Tab Workflow

Dhana — Mon, 07 Sep 2026 16:31:10 +0000

If you've worked on any mid-sized ASP.NET application that uses Session to hold user or transaction context, you've probably run into a bug that looks impossible to reproduce — until you realize the user had two browser tabs open.

Here's the exact scenario I ran into, and why it's more dangerous than it first looks.

The Setup

A user logs in with one ID. That's one Session on the server, tied to that one ASP.NET_SessionId cookie.

Now the user opens two tabs of the same app:

Tab 1: opens Employee A's record — who is eligible for Transaction Type 1
Tab 2: opens Employee B's record — who is eligible for Transaction Type 2

Both tabs are using the same browser session cookie, which means both tabs are reading and writing to the exact same Session object on the server.

Where It Breaks

Say the app stores the currently selected employee and their eligibility flag in Session:

csharp

Session["CurrentEmployeeId"] = employeeId;
Session["EligibleTransactionType"] = eligibilityType;

The user is working in Tab 1 (Employee A), then switches to Tab 2 and opens Employee B. That action overwrites Session["CurrentEmployeeId"] and Session["EligibleTransactionType"] with Employee B's values.

Now the user switches back to Tab 1 and clicks Save. The save action reads eligibility from Session["EligibleTransactionType"] — but that value now belongs to Employee B, not Employee A. If there's no server-side re-validation at the point of save, Employee A's transaction gets saved using Employee B's eligibility rules.

No exception is thrown. No error is logged. The data just quietly becomes wrong.

Why This Is Worse Than a Normal Bug

It's intermittent — only happens with multiple tabs, so it's hard to reproduce in testing
It passes all standard QA — single-tab test cases work fine
It causes silent data corruption, not a crash — which means it can sit undetected in production for a long time
It often gets misdiagnosed as a "random" data issue rather than a session-scoping bug

The Root Cause

The core misunderstanding is this: Session in ASP.NET is scoped to the user's session cookie, not to a browser tab. All tabs in the same browser share the same session cookie by default, so they share the exact same Session object on the server. There is no built-in per-tab isolation.

Junior devs often mentally model Session as "this user's current screen state," when it's really "this user's shared server-side bucket, accessible from anywhere they have a tab open."

How to Actually Fix It

1. Never trust Session state alone for validation at save time.
Re-fetch and re-validate eligibility from the database (or source of truth) at the moment of save, using the entity ID that's actually being saved — not whatever happens to be sitting in Session.

csharp
Bad: trusts session blindly

if (Session["EligibleTransactionType"].ToString() == requestedType) { Save(); }

Better: re-validate against the actual record being saved

var currentEligibility = _employeeService.GetEligibility(employeeIdFromForm);
if (currentEligibility == requestedType) { Save(); }

2. Pass context explicitly through the request, not implicitly through Session.
Instead of relying on Session["CurrentEmployeeId"], pass the employee ID as a hidden field, route parameter, or query string on each screen. Each tab then carries its own context in the request itself, not in a shared server bucket.

3. If you truly need tab-level isolation, use TempData or per-request tokens carefully — not Session.
Session is inherently shared across tabs; if isolated state per tab is a real requirement, look at approaches like encoding context in the URL, using unique form tokens per screen instance, or client-side state management instead of leaning on Session.

4. Add server-side authorization/business rule checks as a final gate before any write.
Treat every save action as if the client could send anything — because in a multi-tab scenario, it effectively can. The last line of defense should always be a fresh check against the source of truth, not a value that was set several clicks ago.

The Takeaway

Session feels like it belongs to "this screen," but it actually belongs to "this user, everywhere they're logged in right now." Any app doing multi-step or multi-screen validation needs to treat Session as a convenience cache, never as the final source of truth at the point of a write. The fix isn't complicated — re-validate on save — but the bug is easy to miss precisely because it only shows up when real users behave in ways your test cases didn't cover.

If your app has any workflow where a user might reasonably have two screens open at once, it's worth auditing every Session-dependent save action today, before it becomes a production incident.