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.
Related
was doing a school project but then came across this error when I was trying to create a table.
CREATE TABLE SSV_PASSENGERS ( PASS_ID# CHAR(6),
PASS_FNAME VARCHAR(15),
PASS_LNAME VARCHAR(15),
PASS_ADDRESS VARCHAR(30),
PASS_NATION VARCHAR(20),
PASS_DOB DATE(yyyy-mm-dd),
PASS SATRATE VARCHAR(2),
PASS_CAB# CHAR(4),
PASS_CABFARE NUMBER(6,2),
PASS_TOTALEX NUMBER(7,2),
PASS_MEDINFO VARCHAR(30),
PASS_DIET VARCHAR(30),
PASS_EMNAME VARCHAR(20),
PASS_EMPHONE# CHAR(10),
PASS_ALTID CHAR(5),
CONSTRAINT SSV_PASSENGERS_PK PRIMARY KEY (PASS_ID#) )
ORA-00907: missing right parenthesis
00907. 00000 - "missing right parenthesis"
Could anyone tell me what's wrong with the script?
The error message ORA-00907: missing right parenthesis indicates a syntax error. Sometimes it means we do actually have a unpaired left bracket. But often it means the compiler has come across an unexpected character, which might be a hanging comma or an unexpected identifier, that the compiler interprets as an attempt to start a new statement without properly closing the current CREATE TABLE statement.
This is not intuitive. However, now you know what the error message really means, the next time you get it you should think to yourself: ah, I have made a typo in my code, I must pore over it until I find my bloomer.
In this case I think the problem is this: PASS_DOB DATE(yyyy-mm-dd).
Oracle stores dates in a standard structure: format masks are just for displaying as or casting from strings.
The way to declare DATE columns is simply: PASS_DOB DATE.
Also, you're missing an underscore from one of your column names: it should be PASS_SATRATE VARCHAR(2).
As far as I see, the parentheses in that statement are balanced. Is it possible the error is reported regarding some different statement?
Oracle allows # as part of column identifiers, but discourages it.
Oracle Database Online Documentation, 10g Release 2 (10.2) / Administration: Schema Object Names and Qualifiers says:
Nonquoted identifiers can contain only alphanumeric characters from your database character set and the underscore (_), dollar sign ($), and pound sign (#). Database links can also contain periods (.) and "at" signs (#). Oracle strongly discourages you from using $ and # in nonquoted identifiers.
(emphasis mine)
Interesting that the same paragraph in the Oracle 12c docs does not include the same warning.
Is it possible that you are executing that create table statement in some environment that treats # as a comment character (like shell or Ruby code) and ignores all the text following the #?
I found a few problems.
DATE (PASS_DOB DATE(yyyy-mm-dd) - you just need DATE
PASS SATRATE VARCHAR(2) - you need an underscore
VARCHAR vs VARCHAR2 - VARCHAR is there to support ANSI - always use VARCHAR2
VARCHAR Datatype The VARCHAR datatype is synonymous with the VARCHAR2
datatype. To avoid possible changes in behavior, always use the
VARCHAR2 datatype to store variable-length character strings.
(Docs)
The working code:
create table SSV_PASSENGERS (
PASS_ID# char(6),
PASS_FNAME varchar2(15),
PASS_LNAME varchar2(15),
PASS_ADDRESS varchar2(30),
PASS_NATION varchar2(20),
PASS_DOB date,
PASS_SATRATE varchar(2),
PASS_CAB# char(4),
PASS_CABFARE number(6,2),
PASS_TOTALEX number(7,2),
PASS_MEDINFO varchar(30),
PASS_DIET varchar(30),
PASS_EMNAME varchar(20),
PASS_EMPHONE# char(10),
PASS_ALTID char(5),
constraint SSV_PASSENGERS_PK primary key ( PASS_ID# )
);
And since you're using and tagged SQL Developer, we try to show you where your problems are, look for the pink squiggles near the offending bad SQL.
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 :)
While I am creating a table In MySql, I am getting an error. I don't know What the problem is, but it will be helpful if I understand the reason behinId it.
Query:
create table publish(
From varcahar(60),
To varchar(60)
);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'From varcahar(60),To varchar(60))' at line 1
Several errors:
1.- From and To are reserverd words you need to escape them
2.- varcahr -> varchar
Final code:
create table publish(
`From` varchar(60),
`To` varchar(60)
);
It says varcahr(60) not varchar(60)
Spelling problem
create table publish(From varchar(60),To varchar(60));
This is the right one. You misspelled varchar
And also From and To are reserved words. Check this Reserved Words In MySql
I have a - for me unknown - issue and I don't know what's the logic/cause behind it. When I try to insert a record in a table I get a DB2 error saying:
[SQL0803] Duplicate key value specified: A unique index or unique constraint *N in *N
exists over one or more columns of table TABLEXXX in SCHEMAYYY. The operation cannot
be performed because one or more values would have produced a duplicate key in
the unique index or constraint.
Which is a quite clear message to me. But actually there would be no duplicate key if I inserted my new record seeing what records are already in there. When I do a SELECT COUNT(*) from SCHEMAYYY.TABLEXXX and then try to insert the record it works flawlessly.
How can it be that when performing the SELECT COUNT(*) I can suddenly insert the records? Is there some sort of index associated with it which might give issues because it is out of sync? I didn't design the data model, so I don't have deep knowledge of the system yet.
The original DB2 SQL is:
-- Generate SQL
-- Version: V6R1M0 080215
-- Generated on: 19/12/12 10:28:39
-- Relational Database: S656C89D
-- Standards Option: DB2 for i
CREATE TABLE TZVDB.PRODUCTCOSTS (
ID INTEGER GENERATED BY DEFAULT AS IDENTITY (
START WITH 1 INCREMENT BY 1
MINVALUE 1 MAXVALUE 2147483647
NO CYCLE NO ORDER
CACHE 20 )
,
PRODUCT_ID INTEGER DEFAULT NULL ,
STARTPRICE DECIMAL(7, 2) DEFAULT NULL ,
FROMDATE TIMESTAMP DEFAULT NULL ,
TILLDATE TIMESTAMP DEFAULT NULL ,
CONSTRAINT TZVDB.PRODUCTCOSTS_PK PRIMARY KEY( ID ) ) ;
ALTER TABLE TZVDB.PRODUCTCOSTS
ADD CONSTRAINT TZVDB.PRODCSTS_PRDCT_FK
FOREIGN KEY( PRODUCT_ID )
REFERENCES TZVDB.PRODUCT ( ID )
ON DELETE RESTRICT
ON UPDATE NO ACTION;
I'd like to see the statements...but since this question is a year old...I won't old my breath.
I'm thinking the problem may be the
GENERATED BY DEFAULT
And instead of passing NULL for the identity column, you're accidentally passing zero or some other duplicate value the first time around.
Either always pass NULL, pass a non-duplicate value or switch to GENERATED ALWAYS
Look at preceding messages in the joblog for specifics as to what caused this. I don't understand how the INSERT can suddenly work after the COUNT(*). Please let us know what you find.
Since it shows *N (ie n/a) as the name of the index or constraing, this suggests to me that is is not a standard DB2 object, and therefore may be a "logical file" [LF] defined with DDS rather than SQL, with a key structure different than what you were doing your COUNT(*) on.
Your shop may have better tools do view keys on dependent files, but the method below will work anywhere.
If your table might not be the actual "physical file", check this using Display File Description, DSPFD TZVDB.PRODUCTCOSTS, in a 5250 ("green screen") session.
Use the Display Database Relations command, DSPDBR TZVDB.PRODUCTCOSTS, to find what files are defined over your table. You can then DSPFD on each of these files to see the definition of the index key. Also check there that each of these indexes is maintained *IMMED, rather than *REBUILD or *DELAY. (A wild longshot guess as to a remotely possible cause of your strange anomaly.)
You will find the DB2 for i message finder here in the IBM i 7.1 Information Center or other releases
Is it a paging issue? we seem to get -0803 on inserts occasionally when a row is being held for update and it locks a page that probably contains the index that is needed for the insert? This is only a guess but it appears to me that is what is happening.
I know it is an old topic, but this is what Google shown me on the first place.
I had the same issue yesterday, causing me a lot of headache. I did the same as above, checked the table definitions, keys, existing items...
Then I found out the problem was with my INSERT statement. It was trying to insert to identical records at once, but as the constraint prevented the commit, I could not find anything in the database.
Advice: review your INSERT statement carefully! :)
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.