Error Messages:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
You're living a dangerous life.
Never, ever create anything in SYS (nor SYSTEM) schema.
Who knows what might be wrong ... maybe you dropped some SYS-owned object. Maybe there's a trigger which does "something" when you create a table.
There's nothing obvious in what you posted. Table, as is, creates normally:
SQL> show user
USER is "SCOTT"
SQL> create table table1
2 (id varchar2(20) not null,
3 ivoice varchar2(20) not null
4 );
Table created.
SQL>
Related
I'm looking to add an identity column to my existing table in oracle apex, but I am being given the invalid ALTER TABLE option error. I've been searching through a lot of threads about this error but I couldn't seem to find anything helpful for this particular problem.
ALTER TABLE tbl_Customer
ADD Customer_ID int Identity(1,1);
I'd appreciate a link to any posts that may be useful, thanks for taking a look.
Wrong syntax. Should be
SQL> create table tbl_customer (name varchar2(20));
Table created.
SQL> alter table tbl_customer add customer_id int generated always as identity;
Table altered.
SQL>
Besides, you are NOT using MySQL as you got ORA-01735 error (which is related to Oracle).
Iam facing a issue while altering the GTT table.
I need to find the active users on that table, Can someone help in query regarding how to find the active users on the specific object in oracle database
As far as I can tell, you didn't explain what problem you're trying to solve, but rather what you think that might help you solve it. So, let me try to guess.
Here's a global temporary table (GTT):
SQL> create global temporary table gtt (id number) on commit preserve rows;
Table created.
SQL> insert into gtt values (1);
1 row created.
SQL> commit;
Commit complete.
You're trying to alter it, but - it fails:
SQL> alter table gtt add name varchar2(10);
alter table gtt add name varchar2(10)
*
ERROR at line 1:
ORA-14450: attempt to access a transactional temp table already in use
OK, so - delete row(s) and commit, then try again:
SQL> delete from gtt;
1 row deleted.
SQL> commit;
Commit complete.
SQL> alter table gtt add name varchar2(10);
alter table gtt add name varchar2(10)
*
ERROR at line 1:
ORA-14450: attempt to access a transactional temp table already in use
Still no luck. But, if you truncate the table, then it works:
SQL> truncate table gtt;
Table truncated.
SQL> alter table gtt add name varchar2(10);
Table altered.
SQL>
If that's not what you're after, then see if this answers your question: connect as a privileged user (such as SYS, if you don't have any other) and run such a query: it shows who owns the GTT, its name, who locked it (which Oracle user) and which operating system user is it (that might help you to contact those people):
SQL> select b.owner,
2 b.object_name,
3 a.oracle_username,
4 a.os_user_name
5 from v$locked_object a, dba_objects b
6 where a.object_id = b.object_id;
OWNER OBJECT_NAM ORACLE_USERNAME OS_USER_NAME
--------------- ---------- --------------- ------------------------------
SCOTT GTT SCOTT littlefoot
SQL>
I'm using Oracle and I have a strange thing.
I dropped a table using :
drop table t_my_table, and committed.
But when I launch select * from t_my_table, it shows the data, as if the table is not dropped.
I tried disconnecting and reconnecting, it stills shows the data when I select.
And when I once again try with :
drop table t_my_table, it tells me that this table does not exist.
But if I run select again, the data is always there.
How is this possible ?
Thank you.
You mean this case?
create view t_my_table as
select 'I''m here' as txt from dual;
drop table t_my_table;
ORA-00942: table or view does not exist
But
select * from t_my_table;
TXT
--------
I'm here
solution of the most probably cause
select OBJECT_TYPE from user_objects where object_name = 'T_MY_TABLE';
OBJECT_TYPE
-------------------
VIEW
You defined a view (or other object type other than TABLE), that can't be dropped with DROP TABLE, but can be selected.
Simple check in USER_OBJECTS the OBJECT_TYPE. You may alternatively see also SYNONYM as proposed in other answer.
Note that it is not a MATERIALIZED VIEW as if you try to drop a Materialized View with DROP TABLE a different error message is raised:
ORA-12083: must use DROP MATERIALIZED VIEW to drop T_MY_TABLE
What does this return?
select * from all_synonyms
where synonym_name = 'T_MY_TABLE';
I suspect there is a synonym T_MY_TABLE that points to a table in a different schema.
drop table t_my_table purge;
Specify PURGE if you want to drop the table and release the space associated with it in a single step. If you specify PURGE, then the database does not place the table and its dependent objects into the recycle bin.
...
Using this clause is equivalent to first dropping the table and then purging it from the recycle bin. This clause lets you save one step in the process. It also provides enhanced security if you want to prevent sensitive material from appearing in the recycle bin.
Probably something different is happening.
Normal case would be:
SQL> create table t1 as select 1 a from dual;
Table T1 created.
SQL> drop table t1;
Table T1 dropped.
SQL> select * from t1;
Error starting at line : 22 in command -
select * from t1
Error at Command Line : 22 Column : 20
Error report -
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
So what was the message after the drop table?
Is t_my_table really a table?
Try select * from all_objects where lower(object_name) = 't_my_table'
How can I stop a SQL statement from running if it's missing a schema qualifier? Most of these issues are caught by a development process, but is there a way to stop the ones that slip through the cracks?
For example, this statement should work:
create table jheller.test_table(a number);
This statement should fail:
create table test_table(a number);
Most of these problems are easily caught during development. Usually a lack of privileges will cause an error like ORA-00942: table or view does not exist. Or if the statement runs successfully on the wrong schema it will cause an obvious error that will be caught during testing.
But inevitably some bad statements still make it into deployments that are promoted to the upper environments. This leads to broken deployments and invalid objects created in schemas like SYS. (We shouldn't be running so many deployments as SYS but that's beyond our control.)
It's not necessary to catch 100% of these issues. But catching 99.9% instead of 99% would make a significant difference.
SQL statements without schema qualifiers can be prevented by:
Creating a fake, empty schema on all databases.
Creating a database trigger to prevent creating objects in that schema.
Setting the session variable CURRENT_SCHEMA to that schema at the beginning of deployment scripts.
Installation - run once per database.
--Create a user. It won't be used so lock it and don't grant it any privileges.
create user schema_qualifier_required identified by "[SOME RANDOM PASSWORD HERE]";
alter user schema_qualifier_required account lock;
--Create trigger to prevent any other user from creating objects on it.
create or replace trigger schema_qualifier_required.no_objects_on_schema_qualifier
before ddl on database
/*
Purpose: SCHEMA_QUALIFIER_REQUIRED exists only to help prevent statements
without schema qualifiers. This trigger ensures no objects can be created in
the schema.
Run this command in a session to help ensure schema qualifiers are used:
alter session set current_schema=schema_qualifier_required;
To drop or modify the schema this trigger must be dropped like this:
alter system set "_system_trig_enabled"=false;
drop trigger schema_qualifier_required.no_objects_on_schema_qualifier
alter system set "_system_trig_enabled"=true;
*/
begin
if ora_dict_obj_owner = 'SCHEMA_QUALIFIER_REQUIRED' then
raise_application_error(-20000, 'You cannot create objects in this schema. '||
'Did you forget to use a schema qualifier in your statement?');
end if;
end;
/
Non-qualified statements initially work.
SQL> create table test1(a number);
Table created.
SQL> select * from test1;
no rows selected
ALTER SESSION to prevent future non-qualified statements from running.
SQL> alter session set current_schema=schema_qualifier_required;
Session altered.
Non-qualified statements no longer work.
SQL> create table test2(a number);
create table test2(a number)
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20000: You cannot create objects in this schema. Did you forget to use a
schema qualifier in your statement?
ORA-06512: at line 3
SQL> select * from test1;
select * from test1
*
ERROR at line 1:
ORA-00942: table or view does not exist
I have not used this method in production yet. If anyone sees problems with this approach or knows of a better way please edit, comment, or add another answer.
My application is giving the "ORA-00942: table or view does not exist" error when in prod environment. Locally it works just fine(when tested locally I am accessing staging DB). On checking the DB in prod I found tables to be there but we have still not populated the values.
To answer your question, no. You cannot receive an ORA-00942 if you are not even connected to the database.
To address your further comments it is probably a matter of properly identifying the table and schema it is in.
conn system/manager;
grant select on hr.employees to scott;
conn scott/scott;
select * from employees;
ORA-00942: table or view does not exist
select * from hr.employees;
<return data>
Alternatively you can create a synonym for the table in the scott schema:
create or replace synonym scott.employees for hr.employees;
This will allow the failed query to succeed as the scott schema has an object called employees in its scope.