oracle error, column not allowed here - oracle

I haven't used Oracle for a while so I'm a bit rusty.
This is my table:
create table calendar(
username VARCHAR2(12),
content VARCHAR2(100),
dateContent DATE,
type CHAR(3) CHECK (type IN ('PUB', 'PRV')));
But when I try to insert a value like this:
insert into calendar
(username, content, dateContent, type)
values
(chris, assignment due, to_date('01-OCT-2010 13:00','DD-MON-YYYY HH24:MI'), PUB)
/
I am getting:
ORA-00984: column not allowed here
pointing to the type column at the end. I have a feeling I'm not getting something right with the DATE field as I've never really used it.
What have I done wrong?

You need to put quotes round the varchar2 values
Something like
insert into calendar(username,
content,
dateContent,
type)
values('chris',
'assignment due',
to_date('01-OCT-2010 13:00','DD-MON-YYYY HH24:MI'),
'PUB');

Could it be because type is a Oracle reserved word ?
Looks like this is not an issue. Read the comment by APC.
I'm not deleting this answer because I find the comment useful.

Related

Oracle 11g "INSERT INTO SELECT" Misbehaving

I am trying to do a very simple thing using the following sample query (can't post the actual query :( )
INSERT INTO Students( id, roll_number, Student_name)
SELECT 1, 2, 'MyName' FROM DUAL;
The ID Column has NOT NULL constraint set. When I execute this query I get the following error:
SQL Error: ORA-01400: cannot insert NULL into ("SCHEMA"."STUDENTS"."ID")
01400. 00000 - "cannot insert NULL into (%s)"
The ID column has datatype NUMBER.
Could anyone help what could be the problem.
Thanks in advance.
What I would do is run the Select part separately, and look at the data that comes back. i.e.
Select First_Field, Second_Field, 'Bob'
From MyTable
Where First_Field = NULL;
What that gives you. You could also do:
Select count(*)
From MyTable
Where coalesce(First_Field,1) =1;
by the way, you said your field is a Numeric, however just FYI. A '' inserted into a varchar2 field gets interpreted as a NULL. Found that out the hard way
Seems like I am creating a habit of answering my own questions...
When I took a closer look into the table I found that there were two ID columns(of course with different names):
One column stores primary key for this table whereas,
other column stores the foreign key as a link to other table.
Thanks everyone for your responses, those made me wonder as to what wrong was I doing.
Thanks a Ton :)

Missing right parenthesis on CREATE TABLE statement

I'm getting an
ORA-00907 error, missing right parenthesis
when attempting to create a table w MySQL.
I have looked extensively on the web but found nothing that could help me here..
Here is my CREATE TABLE statement:
CREATE TABLE station
(
nomStation varchar2(255),
capacite number(15) NOT NULL,
lieu varchar2(255) NOT NULL,
region ENUM('Quebec', 'Ontario', 'NewBrunswick', 'NovaScotia'),
tarif number(10) DEFAULT 0,
CONSTRAINT station_nomStation_pk PRIMARY KEY(nomStation)
);
In my experience, "ORA-00907 error, missing right parenthesis" is usually triggered by a wrong number of commas, like adding an extra comma after your final column or constraint.
However, in your case some googling seems to indicate that Oracle doesn't support the ENUM syntax you're using. Instead, you should use a CHECK, like described in this blog post.

Comparing Date column to sysdate yields: a non-numeric character was found where a numeric was expected

I've been having a strange issue where the comparison of a date column to SYSDATE yields the following error:
01858. 00000 - "a non-numeric character was found where a numeric was expected"
*Cause: The input data to be converted using a date format model was
incorrect. The input data did not contain a number where a number was
required by the format model.
*Action: Fix the input data or the date format model to make sure the
elements match in number and type. Then retry the operation.
I'm re-creating a MATERIALIZED VIEW; which included some minor changes, and whenever the process aborts it always points to the '>=' in the following derived table query:
SELECT id,
desc,
start_date,
end_date
FROM T_LIPR_POLICY_ROLE TLPR
WHERE end_date >= SYSDATE
Now end_date is a type DATE, and I can actually execute this query by itself, but whenever I try to run it in the materialized view it always aborts with the error above. Although last week I was able to create it with the same query.
Any ideas?
Thank you,
Hi I'm terribly sorry for the long delay. I just couldn't post the whole statement for security reasons.
Now the issue has been resolved. The problem was that our materialized view script was aggregating data from 17 different places vía a UNIONs. Now for some reason the error was pointing to wrong line of code (see below).
SELECT id,
desc,
start_date,
end_date
FROM T_LIPR_POLICY_ROLE TLPR
WHERE end_date >= SYSDATE <-- ORACLE POINTS TO THIS LINE
Now this was like the tenth statement in the script, but the error really was in the sixth statement in the script; which was obviously misleading. In this statement a particular record (out of millions) was attempting the following operation:
to_date(' / 0/ ') <-- This was the cause of the problem.
Note that this text wasn't like this in the actual script it literally said to_date(<column name of type varchar>), but 2 records out of 15 million had the text specified above.
Now what I don't quite get is why Oracle points to the wrong line of code.
¿Is it an Oracle issue?
¿Is it a problem with the SQL Developer?
¿Could it be a conflict with a hint? We use several like this: /*+ PARALLEL (init 4) */
Thank you for all your help.
Is desc a column name? If yes then you are using a oracle reserved keyword desc as a column name.
SELECT id,
desc,---- here
start_date,
end_date
FROM T_LIPR_POLICY_ROLE TLPR
WHERE end_date >= SYSDATE
We cannot use oracle reserved keywords in column names.
Please change the column name.

plsql for inserting a table

declare
dno number(4);
dname varchar2(5);
ddate date;
dbasic number(10);
djob varchar2(15);
dcomm number(5);
dept number(5);
dmgr number(5);
begin
select empno,ename,hiredate,sal,job1,comm,deptno,mgr
into dno,dname,ddate,dbasic,djob,dcomm,dept,dmgr
from emp
where empno=&userno;
if sql%rowcount>0
then
insert into newempl
values(dno,dname,djob,dmgr,ddate,dbasic,dcomm,dept);
dbms_output.put_line('records inserted into it');
dbms_output.put_line(dno||' '||dname||' '||ddate||' '||dbasic);
end if;
end;
Error report:
ORA-01858: a non-numeric character was found where a numeric was expected
ORA-06512: at line 19
01858. 00000 - "a non-numeric character was found where a numeric was expected"
*Cause: The input data to be converted using a date format model was
incorrect. The input data did not contain a number where a number was
required by the format model.
*Action: Fix the input data or the date format model to make sure the
elements match in number and type. Then retry the operation.
I do not understand what the error is.
From the error message it looks like you're inserting values into the wrong columns. Without seeing your table structure (from describe newmpl for example) this is a bit of a guess, but this statement:
insert into newempl
values(dno,dname,djob,dmgr,ddate,dbasic,dcomm,dept);
... is assuming that the columns in the newempl table are in a certain order, which may not be (and appears to not be) the case. More specifically here, I think it's complaining about hiredate, as you're implicitly putting the djob value in that column - assuming the new table looks like emp - and the djob value can't be converted into a date.
Update based on comment: from how you said you created the table, this is equivalent to:
insert into newempl(dno, dname, ddate, dbasic, djob, dcomm, dept, dmgr)
values(dno,dname,djob,dmgr,ddate,dbasic,dcomm,dept);
... so as you can see when it's laid out like that the columns are not aligned, and you are indeed trying to put your djob value into the ddate column, which won't work.
It is always safer to explicitly specify the columns, both to prevent problems with different ordering in different environments (though that shouldn't really happen with controlled code) and to prevent this breaking if a new column is added. Something like:
insert into newempl(empno,ename,jon1,mgr,hiredate,sal,comm,deptno)
values(dno,dname,djob,dmgr,ddate,dbasic,dcomm,dept);
As an aside, when declaring your local variables you could specify them based on the table, for example dno emp.empno%TYPE. And as another aside based on your comment, I'd recommend giving local variables different names to the table columns to avoid confusion.
As a_horse_with_no_name said, this can be done with a simple SQL insert, and even within a PL/SQL block it doesn't need separate select and insert statements; you could just do:
insert into newempl(empno,ename,jon1,mgr,hiredate,sal,comm,deptno)
select empno,ename,jon1,mgr,hiredate,sal,comm,deptno
from emp
where empno=&userno;
Unfortunately none of this addresses the requirement that 'the employees who are managers must be inserted into new table', since you aren't doing anything with the mgr column. I don't think it would be constructive to do that part of the task for you at this point though, and I'm not sure where &userno fits in to that.

Inserting data into Oracle

I am trying to migrate a DB from Informix to Oracle.Informix had an option like while inserting into a table if the size of the value exceeds the column length then Informix automatically trims the data.But Oracle does not support this and always throws an exception.Is there a way to prevent and allow trim or we have to respect religiously?
There is no automatic trimming of data in Oracle, you have to trim it explicitly yourself e.g.
insert into mytable (id, text) values (123, substr(var,1,4000));
Oracle does support a variety of SQL functions which trim variables. I suspect the one you'll want is 'SUBSTR()'. The problem is that you will need to specify the desired length explicitly. In this example T23.WHATEVER is presumed to be VARCHAR2(30) and T24.TOO_LONG_COLUMN is, er, longer:
insert into t23
(id
, whatever)
select pk_col
, substr(too_long_col, 1, 30)
from t42
/
As well as Tony's suggestion, you can use a CAST
select cast ('1234' as varchar2(3)) a
from dual
If you are doing data migration, look into DML Error Logging
Having all your non-conformant data put into a corresponding table with the failure reason is positively dreamy.

Resources