I have a SQL file exported from Oracle Express (most probably with Navicat Lite), and there are queries of creating triggers.
But after I imported the file with APEX (SQL Workshop -> SQL Script), the triggers are not created successfully, with no errors.
The queries are like this, they are definitely valid, and I can successfully create the triggers when I manually run these queries with SQL Command.
create or replace TRIGGER "RESENV"."AREA_ID_AUTOINCREMENT" BEFORE INSERT ON "RESENV"."AREA" REFERENCING OLD AS "OLD" NEW AS "NEW" FOR EACH ROW WHEN (new.id is null)
begin
select area_id_seq.nextval into :new.id from dual;
end;;
-- ----------------------------
-- Checks structure for table "RESENV"."AREA"
-- ----------------------------
ALTER TABLE "RESENV"."AREA" ADD CHECK ("ID" IS NOT NULL);
ALTER TABLE "RESENV"."AREA" ADD CHECK ("NAME" IS NOT NULL);
-- ----------------------------
-- Checks structure for table "RESENV"."DATASET"
-- ----------------------------
ALTER TABLE "RESENV"."DATASET" ADD CHECK ("SYSTEM_ID" IS NOT NULL);
ALTER TABLE "RESENV"."DATASET" ADD CHECK ("AREA_ID" IS NOT NULL);
ALTER TABLE "RESENV"."DATASET" ADD CHECK ("TABLE_NAME" IS NOT NULL);
ALTER TABLE "RESENV"."DATASET" ADD CHECK ("CREATED" IS NOT NULL);
-- ----------------------------
-- Triggers structure for table "RESENV"."IDX"
-- ----------------------------
CREATE OR REPLACE TRIGGER "RESENV"."IDX_ID_AUTOINCREMENT" BEFORE INSERT ON "RESENV"."IDX" REFERENCING OLD AS "OLD" NEW AS "NEW" FOR EACH ROW ENABLE WHEN (new.id is null)
begin
select idx_id_seq.nextval into :new.id from dual;
end;;
-- ----------------------------
-- Checks structure for table "RESENV"."IDX"
-- ----------------------------
ALTER TABLE "RESENV"."IDX" ADD CHECK ("ID" IS NOT NULL);
-- ----------------------------
-- Triggers structure for table "RESENV"."SYSTEM"
-- ----------------------------
CREATE OR REPLACE TRIGGER "RESENV"."SYSTEM_ID_AUTOINCREMENT" BEFORE INSERT ON "RESENV"."SYSTEM" REFERENCING OLD AS "OLD" NEW AS "NEW" FOR EACH ROW ENABLE WHEN (new.id is null)
begin
select SYSTEM_ID_SEQ.nextval into :new.id from dual;
end;;
-- ----------------------------
-- Checks structure for table "RESENV"."SYSTEM"
-- ----------------------------
ALTER TABLE "RESENV"."SYSTEM" ADD CHECK ("ID" IS NOT NULL);
ALTER TABLE "RESENV"."SYSTEM" ADD CHECK ("SYSTEM_CREATED" IS NOT NULL);
ALTER TABLE "RESENV"."SYSTEM" ADD CHECK ("SYSTEM_MODIFIED" IS NOT NULL);
ALTER TABLE "RESENV"."SYSTEM" ADD CHECK ("USER_ID" IS NOT NULL);
-- ----------------------------
-- Checks structure for table "RESENV"."UNIT"
-- ----------------------------
ALTER TABLE "RESENV"."UNIT" ADD CHECK ("ID" IS NOT NULL);
ALTER TABLE "RESENV"."UNIT" ADD CHECK ("NAME" IS NOT NULL);
ALTER TABLE "RESENV"."UNIT" ADD CHECK ("GD_ID" IS NOT NULL);
ALTER TABLE "RESENV"."UNIT" ADD CHECK ("AREA_ID" IS NOT NULL);
-- ----------------------------
-- Checks structure for table "RESENV"."USERS"
-- ----------------------------
ALTER TABLE "RESENV"."USERS" ADD CHECK ("ID" IS NOT NULL);
ALTER TABLE "RESENV"."USERS" ADD CHECK ("NAME" IS NOT NULL);
ALTER TABLE "RESENV"."USERS" ADD CHECK ("PASSWORD" IS NOT NULL);
-- ----------------------------
-- Checks structure for table "RESENV"."VLUE"
-- ----------------------------
ALTER TABLE "RESENV"."VLUE" ADD CHECK ("ID" IS NOT NULL);
ALTER TABLE "RESENV"."VLUE" ADD CHECK ("UNIT_ID" IS NOT NULL);
ALTER TABLE "RESENV"."VLUE" ADD CHECK ("IDX_ID" IS NOT NULL);
ALTER TABLE "RESENV"."VLUE" ADD CHECK ("IDX_VALUE" IS NOT NULL);
I have tried many times, and same result.
Why this happen? Is this a bug of APEX?
UPDATE
I have these lines shown above at the end of the SQL file (before those are the lines of creating tables and inserting data), but APEX treated all these lines as ONE statement, and created only one trigger whose code is as above (of course there is an error in the code of the trigger, but APEX didn't mention that when run the SQL script).
I have tried with Navicat to import the dump file (with Execute SQL file function). And the errors are as listed, which I think it should be OK.
Update 2
It turns out I have to add a slash / at the end of each create trigger statement, otherwise there can only be one trigger created in each script file.
see this questin
But the triggers still have errors with the above statements and a slash.
The code is:
create or replace TRIGGER "RESENV"."SYSTEM_ID_AUTOINCREMENT" BEFORE INSERT ON "RESENV"."SYSTEM" REFERENCING OLD AS "OLD" NEW AS "NEW" FOR EACH ROW WHEN (new.id is null)
begin
select SYSTEM_ID_SEQ.nextval into :new.id from dual;
end;;
and the error is: Line 3 Position 5, PLS-00103: Encountered the symbol ";"
I don't know why navcat exported like this.
Update
It turns out that the double semicolons caused the problem. After I removed one, there is no error any more.
Related
I want to create table to save all CONSTRAINTs changes in my oracle database,
so i have created this table(table name , constraint name , date , mode like [insert|update|delete] )
CREATE TABLE CONS
(
C_ID NUMBER NOT NULL
, C_NAME VARCHAR2(50) NOT NULL
, T_NAME VARCHAR2(50) NOT NULL
, EXE_DATE DATE NOT NULL
, MODE VARCHAR2(50) NOT NULL
);
the problem was by insert data,
I was thinking of creating trigger on user_cons_columns after insert or update or delete,
but I found that user_cons_columns is a view and i can't create trigger on it,
so how can I do this work?
or what is the tables that I can create trigger on it to do this???
thanks .......
User_Cons_Columns is metadata view in oracle and you can not use it for monitoring constraint changes.
I think, You can use this metadata view :
SELECT *
FROM ALL_CONSTRAINTS T
It shows which constraint has changed by LAST_CHANGE Column and other data that you can use them.
I don't know if we can create DML TRIGGERs on data dictionary tables in Oracle, but that sounds like a bad idea.
My suggestion to you would be to create a DDL Trigger on the ALTER event
Firstly, as a one time activity, you could store all the available constraints in your CONS table.
Then in your trigger, you could use these conditions to check if a table and column was altered.
if (ora_sysevent = 'ALTER' and
ora_dict_obj_type = 'TABLE')
then alter_column :=
ora_is_alter_column('FOO');
end if;
You could then query the user_cons_columns , ALL_CONSTRAINTS and CONS - whichever you find is relevant to store your data - to find if a new constraint was added or not. If it was indeed added or modified, make an entry into CONS or else update it ( using MERGE statement )
As you said, you can't create that type of a trigger on USER_CONS_COLUMNS:
SQL> create or replace trigger trg_myucc
2 before insert
3 on user_cons_columns
4 begin
5 null;
6 end;
7 /
create or replace trigger trg_myucc
*
ERROR at line 1:
ORA-25001: cannot create this trigger type on this type of view
Why wouldn't we try INSTEAD OF TRIGGER?
SQL> create or replace trigger trg_myucc
2 instead of insert
3 on user_cons_columns
4 for each row
5 begin
6 null;
7 end;
8 /
on user_cons_columns
*
ERROR at line 3:
ORA-01031: insufficient privileges
OK, that won't work either. But, what prevents us on creating a view upon a view, and then create INSTEAD OF trigger on that newly created view?
SQL> create or replace view my_ucc as select * from user_cons_columns;
View created.
SQL> create or replace trigger trg_myucc
2 instead of insert
3 on my_ucc
4 for each row
5 begin
6 null;
7 end;
8 /
Trigger created.
Fine; now you have a way to do what you're supposed to do. More about triggers here.
I would receive an error:
ORA-02437: cannot validate (%s.%s) - primary key violated
Cause: attempted to validate a primary key with duplicate values or null values
I found it was because I have a stored procedure that increments the ID, but it had failed to do so when it re-ran and had an error related to one of my datatypes. I found I now had a duplicate ID in my database table. All this made sense and I was able to easily rectify it with a DELETE FROM MyTable WHERE ID = x, where x was the offending duplicate ID. The problem I have is the only way I was able to even find the IDs that were duplicated is in the first place is because I did a SELECT * FROM MyTable WHERE ID = x -- where x was one greater than the last ID I could actually see. I found it just by an educated guess. So:
Why can't I see these duplicate IDs when I open the table in Oracle SQL Developer? It only shows the last row as the ID before the duplicates. I don't think it is because of my primary key constraint, since the first line in my stored procedure is to remove that (and put it back, at the end - probably when I got my error), and it was not present when I looked at my table.
Is there some way to make these last IDs that got inserted into the table visible, so I wouldn't have to guess or assume that the duplicate IDs are "hiding" as one greater than the last ID I have in my table, in the future? There is a commit; in my stored procedure, so they should have appeared -- unless, of course, the procedure got hung up before it could run that line of code (highly probable).
Stored procedure that runs:
create or replace
PROCEDURE PRC_MYTABLE_INTAKE(
, EMPLOYEE_ID IN NVARCHAR2
, TITLE_POSITION IN NVARCHAR2
, CREATED_DATE IN DATE
, LAST_MODIFIED IN DATE
) AS
myid integer := 0;
appid integer := 0;
BEGIN
-- disable PK constraint so it can be updated
EXECUTE IMMEDIATE 'ALTER TABLE MYTABLE DROP CONSTRAINT MYTABLE_PK';
COMMIT;
-- assign ID to myid
SELECT ID INTO myid FROM MYTABLE WHERE ROWID IN (SELECT MAX(ROWID) FROM MYTABLE);
-- increment
myid := myid + 1;
-- assign APPLICATION_ID to appid
SELECT APPLICATION_ID INTO appid FROM MYTABLE WHERE ROWID IN (SELECT MAX(ROWID) FROM MYTABLE);
-- increment
appid := appid + 1;
-- use these ids to insert with
INSERT INTO MYTABLE (ID, APPLICATION_ID,
, EMPLOYEE_ID
, TITLE_POSITION
, CREATED_DATE
, LAST_MODIFIED
) VALUES(myid, appid,
, EMPLOYEE_ID
, TITLE_POSITION
, CREATED_DATE
, LAST_MODIFIED
);
COMMIT;
-- re-enable the PK constraint
EXECUTE IMMEDIATE 'ALTER TABLE PASS ADD CONSTRAINT MYTABLE_PK PRIMARY KEY (ID)';
COMMIT;
END;
Here's one problem:
SELECT ID
INTO myid
FROM MYTABLE
WHERE ROWID IN (SELECT MAX(ROWID) FROM MYTABLE)
There is no correlation between ID and ROWID, so you're not getting the maximum current ID, you're just getting the one that happens to be on the row that is furthest from the start of a datafile with a high number.
The code you need is:
SELECT COALESCE(MAX(ID),0)
FROM MYTABLE;
Or better yet, just use a sequence.
No idea why you're dropping the PK either.
Furthermore, when you issue the query:
SELECT APPLICATION_ID INTO appid ...
... that could be for a different row than the one you already got the id for, because a change could have been committed to the table.
Of course another issue is that you can't run two instances of this procedure at the same time either.
For David Aldridge, since he wants to look at code instead of the real reason I posted my question, run this ---
CREATE TABLE YOURSCHEMA.TESTING
(
TEST_ID NVARCHAR2(100) NOT NULL
, TEST_TYPE NVARCHAR2(100) NOT NULL
, CONSTRAINT TEST_PK PRIMARY KEY
(
TEST_ID
)
ENABLE
);
create or replace
PROCEDURE PRC_TESTING_INSERT(
TEST_TYPE IN NVARCHAR2
) AS
testid integer := 0;
BEGIN
-- disable PK constraint so it can be updated
EXECUTE IMMEDIATE 'ALTER TABLE TESTING DROP CONSTRAINT TEST_PK';
COMMIT;
-- assign TEST_ID to testid
SELECT TEST_ID INTO testid FROM TESTING WHERE ROWID IN (SELECT MAX(ROWID) FROM TESTING);
-- increment
testid := testid + 1;
-- use this id to insert with
INSERT INTO TESTING (TEST_ID, TEST_TYPE) VALUES(testid, TEST_TYPE);
COMMIT;
-- re-enable the PK constraint
EXECUTE IMMEDIATE 'ALTER TABLE TESTING ADD CONSTRAINT TEST_PK PRIMARY KEY (TEST_ID)';
COMMIT;
END;
SET serveroutput on;
DECLARE
test_type varchar(100);
BEGIN
test_type := 'dude';
YOURSCHEMA.PRC_TESTING_INSERT(test_type);
-- to verify the variable got set and procedure ran, could do:
--dbms_output.enable;
--dbms_output.put_line(test_type);
END;
Now, because there is no data in the table, the stored procedure will fail with ORA-06512: no data found. If you then try and run it again, you will get ORA-02443: cannot drop constraint - nonexistent constraint, because the EXECUTE IMMEDIATE 'ALTER TABLE TESTING DROP CONSTRAINT TEST_PK'; successfully dropped it, and the procedure never ran the command at the end to re-add it. This is what made me think I needed the commits, but even without them, it still will not complete the whole procedure.
To prove that the procedure DOES run, if given proper data, run this after creating the table, but before creating/running the stored procedure:
INSERT INTO TESTING (TEST_ID, TEST_TYPE)
VALUES ('1', 'hi');
And if you run the proc from a new table (not one with its constraint dropped), it will run fine.
Since mathguy didn't post this as the answer, though I'll credit him for the information...
Answer to why I can't see the duplicates is because the COMMIT does not occur in the procedure when it failed due to a datatype mismatch (which we found was actually in the application's code that sent the variable's values into this procedure, not in the stored procedure, itself). (It's also why I'll mark down anyone that says you don't have to add so many COMMIT lines in this procedure.) The commands were run in the session of the user that starts it - in my case, another session of the same DB user I was logged in with, but started from my application, instead of my SQL Developer session. It also explains why I could do a COMMIT, myself, but it did not affect the application's session - I could not commit any actions ran from another session. Had I ran a COMMIT as an OracleCommand and did an .ExecuteNonQuery on my OracleConnection right after the failure within the catch of my application, I would have seen the rows in SQL Developer without having to do a special query.
So, in short, the only way to see the items was with a direct query using WHERE ID =, find the last ID and increment it, and put it in the query.
When I ran the alter query, I get error saying that column to be modified must me empty.
Table : Monthly_Result (Id Number(38,0), dealer_ID varchar2, sales_revenue Number(38,2))
dealer_Id should be changed to Number(38,0)
Please help
As Alex mentioned in his comment you will need to add new column; update it and check values were converted correctly; then drop the old column when you're ready.
-- step 1
alter table monthly_result add tmp number(38, 0);
update monthly_result set tmp = to_number(dealer_id);
-- step 2
-- check values are set correctly in tmp
-- step 3
alter table monthly_result rename column dealer_id to dealer_id_old;
alter table monthly_result rename column tmp to dealer_id;
-- step 4
alter table monthly_result drop column dealer_id_old;
Please try this it would be help the update add column things you will loss your primary key and position of the table:
--COPY THE DATA TO TEMPORARY TABLE
CREATE TABLE _TMP AS SELECT * FROM ;
--TRUNCATE OLD DATA
TRUNCATE TABLE ;
--ALTER SPECIFIC COLUMN TYPE
alter table MODIFY number(38, 0);
--BRING THE DATA FROM WHICH COPY PREVIOUS TEMPORARY TABLE
INSERT INTO SELECT * FROM _TMP;
--CHECK YOUR DATA
SELECT * FROM ;
--DROP YOUR TEMPORARY TABLE
DROP TABLE _TMP;
I believe it will work for you.
I create a table in Oracle 11g with the default value for one of the columns. Syntax is:
create table xyz(emp number,ename varchar2(100),salary number default 0);
This created successfully. For some reasons I need to create another table with same old table structure and data. So I created a new table with name abc as
create table abc as select * from xyz.
Here "abc" created successfully with same structure and data as old table xyz. But for the column "salary" in old table "xyz" default value was set to "0". But in the newly created table "abc" the default value is not set.
This is all in Oracle 11g. Please tell me the reason why the default value was not set and how we can set this using select statement.
You can specify the constraints and defaults in a CREATE TABLE AS SELECT, but the syntax is as follows
create table t1 (id number default 1 not null);
insert into t1 (id) values (2);
create table t2 (id default 1 not null)
as select * from t1;
That is, it won't inherit the constraints from the source table/select. Only the data type (length/precision/scale) is determined by the select.
The reason is that CTAS (Create table as select) does not copy any metadata from the source to the target table, namely
no primary key
no foreign keys
no grants
no indexes
...
To achieve what you want, I'd either
use dbms_metadata.get_ddl to get the complete table structure, replace the table name with the new name, execute this statement, and do an INSERT afterward to copy the data
or keep using CTAS, extract the not null constraints for the source table from user_constraints and add them to the target table afterwards
You will need to alter table abc modify (salary default 0);
new table inherits only "not null" constraint and no other constraint.
Thus you can alter the table after creating it with "create table as" command
or you can define all constraint that you need by following the
create table t1 (id number default 1 not null);
insert into t1 (id) values (2);
create table t2 as select * from t1;
This will create table t2 with not null constraint.
But for some other constraint except "not null" you should use the following syntax
create table t1 (id number default 1 unique);
insert into t1 (id) values (2);
create table t2 (id default 1 unique)
as select * from t1;
I want to disable NOT NULL constraints into a table to insert data for test but I can't find a way to disable unnamed constraints.
I found enough info to disable named constraints, but I couldn't find a example to disable unnamed NOT NULL constraint.
I would like to implement this without querying the data dictionary, but... I'm willing to do that if its the only way. But I would like to use a clean ALTER TABLE DDL.
You will need to query the data dictionary, something like this will disable all constraints on the table. Be aware though, that this will disable the constraint system wide, not just for your session.. Perhaps what you really want is to defer the constraint?
drop table testxx
drop table testxx succeeded.
create table testxx ( id number not null )
create table succeeded.
select status from user_constraints where table_name = 'TESTXX'
STATUS
--------
ENABLED
1 rows selected
begin
for cnames in ( select table_name,constraint_name from user_constraints where table_name = 'TESTXX' ) loop
execute immediate 'alter table ' || cnames.table_name || ' disable constraint ' || cnames.constraint_name;
end loop;
end;
anonymous block completed
select status from user_constraints where table_name = 'TESTXX'
STATUS
--------
DISABLED
1 rows selected
You can also just alter the column as follows
create table test_null (col_n number not null);
alter table test_null modify col_n number null;