Oracle raises ORA-00942: table or view does not exist when a statement names an object the current schema cannot see. The wording is broader than it sounds: Oracle deliberately gives the same error for “the object is in another schema and you have no privilege on it” as for “there is no such object”, so the error cannot be used to probe what exists in other schemas. In practice the cause ranking is: the object belongs to another schema and needs a schema prefix or a synonym plus a grant, it was never created in this database, or the name (including its case) does not match.
SELECT owner, object_name, object_type FROM all_objects WHERE object_name = 'EMPLOYEES'; (object names are stored uppercase unless quoted at creation). If it appears under another owner, the object exists; your session needs the schema-qualified name (HR.EMPLOYEES) or a synonym, and a privilege grant from the owner.dba_objects as a DBA, or accept the likely truth: the object was never created here (a migration or setup script that did not run, the wrong database or environment, a dropped object).CREATE TABLE "Employees") must be referenced with the same quotes and case forever; unquoted references fold to uppercase and miss it, producing this exact error on a table that plainly “exists”.GRANT SELECT ON hr.employees TO app_user;, the receiving user cannot take it. And a grant made to a role the user has, but through a view or a stored procedure, has its own well-known wrinkle: definer's-rights procedures need direct grants, not role grants.The table exists, I can see it in my tool, why does the query fail? Your tool may be connected as a different user, or browsing all schemas. The failing session resolves names in its own schema plus its synonyms; if the object belongs to another schema, qualify it with the owner name and confirm the privilege, the visibility, not the existence, is the issue.
Why does Oracle not just say “permission denied”? By design, to avoid leaking the existence of objects across schemas. ORA-00942 covers both cases so an unauthorized user cannot enumerate other schemas' tables by testing names.
It worked before the weekend, what changed? Typical causes: the object was dropped and recreated under a different owner, a synonym was dropped, or privileges were revoked or the deployment connected as a different user. The dictionary queries above distinguish them in one pass.