This question already has answers here:
View based on apex collection
(2 answers)
Can't use column names in select query on sqlfiddle (oracle)
(3 answers)
Closed 2 months ago.
I have a table with 43 columns. When I execute "Select * from My_Table", it works; And shows data of all columns.
But if I perform "Select" query on some of the columns ( In my case, the first 29 columns of the table)
I receive an error that says "INVALID IDENTIFIER".
Other columns work just fine.
I can't perform "group by" or "order by" using these 29 columns either.
What do you think is the problem?
Any help is appreciated.
Some screenshots are attached for better understanding.
Looking at screenshots, it seems that you created table using mixed letter case and enclosed column names into double quotes. If that's so, well - that's usually bad idea in Oracle as you'll always have to identify columns that way: match letter case and use double quotes.
Therefore, that would be e.g.
select "Order_Id", "Customer_name", "DATA_DATE"
from your_table
Looks awful ... will you remember that customer name doesn't have initial capital letters, but e.g. trace number does?
For you own sake, if possible, drop that table and create a new one as
create table your_table
(order_id number,
customer_name varchar2(20),
trace_number number,
...
);
and reference such a table and columns using any letter case (as it'll work because - by default - Oracle stores names in uppercase (into data dictionary), but lets you reference them any way you want):
select order_id, CUSTOMER_name, TRacE_NumBER ...
The issue is when querying a table created using Aqua Data Studio in our IBM DB2 database, column names can't be specified unless I use the system name. Tables made a short time ago don't have this issue. The query can find the column names just fine in them. There also is not a problem using wildcards and the column names display just fine.
For clarity:
this works : SELECT * FROM WUNITS.DVIRS
this works : SELECT ID___00001 FROM WUNITS.DVIRS
This doesn't : SELECT Id FROM WUNITS.DVIRS
This does work for older tables created the same way : SELECT Id FROM WUNITS.DVIRS
Here is a screenshot of the column definitions
What am I doing wrong?
Since you mention system name, I'll assume you're using Db2 for IBM i....
I suspect you've created the table with quoted column names...you wouldn't see mixed case column names otherwise, they would be all CAPITALS.
For example:
create table dtcwilt.dvirs (
"Id" bigint
, "AssetNumber" varchar(25)
, WoNumber bigint
, WoStatusId int
)
Not sure what tool you're using to display the columns, but the ACS schema tool would show the quoted name.
The quotes are actually part of the name, you'd need to use the quoted name, with proper capitalization, in your select:
This should work:
SELECT "Id" FROM WUNITS.DVIRS
This would not:
SELECT "ID" FROM WUNITS.DVIRS
Is there any term like 'DOT(.) notation' used in SQL joins?
if practised, pls explain how to use it.
Thanks in advance.
Yes here is how you do it
When you do your SELECT
SELECT firstname, lastname from dbo.names n -- The n becomes an alias
JOIN address a --- another alias
on a.userid = n.userid
Collated from multiple sources of official documentation.
Dot notation (sometimes called the membership operator) allows you to qualify an SQL identifier with another SQL identifier of which it is a component. You separate the identifiers with the period ( . ) symbol. For example, you can qualify a column name with any of the following SQL identifiers:
Table name: table_name.column_name
View name: view_name.column_name
Synonym name: syn_name.column_name
These forms of dot notation are called column projections.
You can also use dot notation to directly access the fields of a named or unnamed ROW column, as in the following example:
row-column name.field name
This use of dot notation is called a field projection. For example, suppose you have a column called rect with the following definition:
CREATE TABLE rectangles
(
area float,
rect ROW(x int, y int, length float, width float)
)
The following SELECT statement uses dot notation to access field length of the rect column:
SELECT rect.length FROM rectangles WHERE area = 64
Selecting Nested Fields
When the ROW type that defines a column itself contains other ROW types, the column contains nested fields. Use dot notation to access these nested fields within a column.
For example, assume that the address column of the employee table contains the fields: street, city, state, and zip. In addition, the zip field contains the nested fields: z_code and z_suffix. A query on the zip field returns values for the z_code and z_suffix fields. You can specify, however, that a query returns only specific nested fields. The following example shows how to use dot notation to construct a SELECT statement that returns rows for the z_code field of the address column only:
SELECT address.zip.z_code
FROM employee
Rules of Precedence
The database server uses the following precedence rules to interpret dot notation:
schema name_a . table name_b . column name_c . field name_d
table name_a . column name_b . field name_c . field name_d
column name_a . field name_b . field name_c . field name_d
When the meaning of an identifier is ambiguous, the database server uses precedence rules to determine which database object the identifier specifies. Consider the following two tables:
CREATE TABLE b (c ROW(d INTEGER, e CHAR(2));
CREATE TABLE c (d INTEGER);
In the following SELECT statement, the expression c.d references column d of table c (rather than field d of column c in table b) because a table identifier has a higher precedence than a column identifier:
SELECT *
FROM b,c
WHERE c.d = 10
For more information about precedence rules and how to use dot notation with ROW columns, see the IBM Informix: Guide to SQL Tutorial.
Using Dot Notation with Row-Type Expressions
Besides specifying a column of a ROW data type, you can also use dot notation with any expression that evaluates to a ROW type. In an INSERT statement, for example, you can use dot notation in a subquery that returns a single row of values. Assume that you created a ROW type named row_t:
CREATE ROW TYPE row_t (part_id INT, amt INT)
Also assume that you created a typed table named tab1 that is based on the row_t ROW type:
CREATE TABLE tab1 OF TYPE row_t
Assume also that you inserted the following values into table tab1:
INSERT INTO tab1 VALUES (ROW(1,7));
INSERT INTO tab1 VALUES (ROW(2,10));
Finally, assume that you created another table named tab2:
CREATE TABLE tab2 (colx INT)
Now you can use dot notation to insert the value from only the part_id column of table tab1 into the tab2 table:
INSERT INTO tab2
VALUES ((SELECT t FROM tab1 t
WHERE part_id = 1).part_id)
The asterisk form of dot notation is not necessary when you want to select all fields of a ROW-type column because you can specify the column name alone to select all of its fields. The asterisk form of dot notation can be quite helpful, however, when you use a subquery, as in the preceding example, or when you call a user-defined function to return ROW-type values.
Suppose that a user-defined function named new_row returns ROW-type values, and you want to call this function to insert the ROW-type values into a table. Asterisk notation makes it easy to specify that all the ROW-type values that the new_row( ) function returns are to be inserted into the table:
INSERT INTO mytab2 SELECT new_row (mycol).* FROM mytab1
References to the fields of a ROW-type column or a ROW-type expression are not allowed in fragment expressions. A fragment expression is an expression that defines a table fragment or an index fragment in SQL statements like CREATE TABLE, CREATE INDEX, and ALTER FRAGMENT.
Additional Examples of How to Specify Names With the Dot Notation
Dot notation is used for identifying record fields, object attributes, and items inside packages or other schemas. When you combine these items, you might need to use expressions with multiple levels of dots, where it is not always clear what each dot refers to. Here are some of the combinations:
Field or Attribute of a Function Return Value
func_name().field_name
func_name().attribute_name
Schema Object Owned by Another Schema
schema_name.table_name
schema_name.procedure_name()
schema_name.type_name.member_name()
Packaged Object Owned by Another User
schema_name.package_name.procedure_name()
schema_name.package_name.record_name.field_name
Record Containing an Object Type
record_name.field_name.attribute_name
record_name.field_name.member_name()
Differences in Name Resolution Between PL/SQL and SQL
The name resolution rules for PL/SQL and SQL are similar. You can avoid the few differences if you follow the capture avoidance rules. For compatibility, the SQL rules are more permissive than the PL/SQL rules. SQL rules, which are mostly context sensitive, recognize as legal more situations and DML statements than the PL/SQL rules.
PL/SQL uses the same name-resolution rules as SQL when the PL/SQL compiler processes a SQL statement, such as a DML statement. For example, for a name such as HR.JOBS, SQL matches objects in the HR schema first, then packages, types, tables, and views in the current schema.
PL/SQL uses a different order to resolve names in PL/SQL statements such as assignments and procedure calls. In the case of a name HR.JOBS, PL/SQL searches first for packages, types, tables, and views named HR in the current schema, then for objects in the HR schema.
Is it possible to create a table with column name containing space? If so how can I create and use it?
It is possible, but it is not advisable. You need to enclose the column name in double quotes.
create table my_table ("MY COLUMN" number);
But note the warning in the documentation:
Note: Oracle does not recommend using quoted identifiers for database
object names. These quoted identifiers are accepted by SQL*Plus, but
they may not be valid when using other tools that manage database
objects.
The name will be case-sensitive, and you wil have to enclose the name in double quotes every time you reference it:
select "MY COLUMN" from my_table;
So... don't, would be my advice...
Yes, it's possible. You just have to be sure to quote the column name. For instance:
CREATE TABLE Fubar ("Foo Bar" INT);
INSERT INTO Fubar VALUES (1337);
SELECT "Foo Bar" FROM SpaceMonster
Even though it's possible, it doesn't make it a good idea. You'll probably save yourself from a lot of pain if just replace all you spaces with underscores.
it is possible by naming the column between two "
example: "My columN" , the column name becomes case sensitive which means.
SELECT "my column" from table; --NOT OK
SELECT "My columN" from table; --OK
You can (see the Oracle doc) if you quote these appropriately. However I suspect this is not a good idea, since you'll have to quote everything. Generally db naming standards / conventions (e.g. here or here) favour using underscores (which don't require quoting) over whitespace.
This is the columns rule defined for oracle
Columns (for tables)
All columns are in form {alias}_{colname}. For example prs_id,
prs_name, prs_adr_id, adr_street_name. This guarantees that column
names are unique in a schema, except denormalized columns from
another table, which are populated using triggers or application
logic.
All columns are in singular. If you think you need a column name in plural think twice whether it is the right design? Usually it
means you are including multiple values in the same column and that
should be avoided.
All tables have surrogate primary key column in form {alias}_id, which is the first column in the table. For example, prs_id, mat_id,
adr_id.
you can always have alias for column name bu using ""
Did you Google for this? I did - the 6th link was this, in which I find the following:
create table employee (
"First Name" varchar2(20),
"Last Name" varchar2(20),
Address varchar2(60),
Phone varchar2(15),
Salary number,
EmpID number,
DeptID number
);
... which works fine when I tried it in 10g.
A very easy one for someone,
The following insert is giving me the
ORA-01722: invalid number
why?
INSERT INTO CUSTOMER VALUES (1,'MALADY','Claire','27 Smith St Caulfield','0419 853 694');
INSERT INTO CUSTOMER VALUES (2,'GIBSON','Jake','27 Smith St Caulfield','0415 713 598');
INSERT INTO CUSTOMER VALUES (3,'LUU','Barry','5 Jones St Malvern','0413 591 341');
INSERT INTO CUSTOMER VALUES (4,'JONES','Michael','7 Smith St Caulfield','0419 853 694');
INSERT INTO CUSTOMER VALUES (5,'MALADY','Betty','27 Smith St Knox','0418 418 347');
An ORA-01722 error occurs when an attempt is made to convert a character string into a number, and the string cannot be converted into a number.
Without seeing your table definition, it looks like you're trying to convert the numeric sequence at the end of your values list to a number, and the spaces that delimit it are throwing this error. But based on the information you've given us, it could be happening on any field (other than the first one).
Suppose tel_number is defined as NUMBER - then the blank spaces in this provided value cannot be converted into a number:
create table telephone_number (tel_number number);
insert into telephone_number values ('0419 853 694');
The above gives you a
ORA-01722: invalid number
Here's one way to solve it. Remove non-numeric characters then cast it as a number.
cast(regexp_replace('0419 853 694', '[^0-9]+', '') as number)
Well it also can be :
SELECT t.col1, t.col2, ('test' + t.col3) as test_col3
FROM table t;
where for concatenation in oracle is used the operator || not +.
In this case you get : ORA-01722: invalid number ...
This is because:
You executed an SQL statement that tried to convert a string to a
number, but it was unsuccessful.
As explained in:
Oracle/PLSQL: ORA-01722 Error.
To resolve this error:
Only numeric fields or character fields that contain numeric values
can be used in arithmetic operations. Make sure that all expressions
evaluate to numbers.
As this error comes when you are trying to insert non-numeric value into a numeric column in db it seems that your last field might be numeric and you are trying to send it as a string in database. check your last value.
Oracle does automatic String2number conversion, for String column values! However, for the textual comparisons in SQL, the input must be delimited as a String explicitly: The opposite conversion number2String is not performed automatically, not on the SQL-query level.
I had this query:
select max(acc_num) from ACCOUNTS where acc_num between 1001000 and 1001999;
That one presented a problem: Error: ORA-01722: invalid number
I have just surrounded the "numerical" values, to make them 'Strings', just making them explicitly delimited:
select max(acc_num) from ACCOUNTS where acc_num between '1001000' and '1001999';
...and voilà: It returns the expected result.
edit:
And indeed: the col acc_num in my table is defined as String. Although not numerical, the invalid number was reported. And the explicit delimiting of the string-numbers resolved the problem.
On the other hand, Oracle can treat Strings as numbers. So the numerical operations/functions can be applied on the Strings, and these queries work:
select max(string_column) from TABLE;
select string_column from TABLE where string_column between '2' and 'z';
select string_column from TABLE where string_column > '1';
select string_column from TABLE where string_column <= 'b';
In my case the conversion error was in functional based index, that I had created for the table.
The data being inserted was OK. It took me a while to figure out that the actual error came from the buggy index.
Would be nice, if Oracle could have gave more precise error message in this case.
If you do an insert into...select * from...statement, it's easy to get the 'Invalid Number' error as well.
Let's say you have a table called FUND_ACCOUNT that has two columns:
AID_YEAR char(4)
OFFICE_ID char(5)
And let's say that you want to modify the OFFICE_ID to be numeric, but that there are existing rows in the table, and even worse, some of those rows have an OFFICE_ID value of ' ' (blank). In Oracle, you can't modify the datatype of a column if the table has data, and it requires a little trickery to convert a ' ' to a 0. So here's how to do it:
Create a duplicate table: CREATE TABLE FUND_ACCOUNT2 AS SELECT * FROM FUND_ACCOUNT;
Delete all the rows from the original table: DELETE FROM FUND_ACCOUNT;
Once there's no data in the original table, alter the data type of its OFFICE_ID column: ALTER TABLE FUND_ACCOUNT MODIFY (OFFICE_ID number);
But then here's the tricky part. Because some rows contain blank OFFICE_ID values, if you do a simple INSERT INTO FUND_ACCOUNT SELECT * FROM FUND_ACCOUNT2, you'll get the "ORA-01722 Invalid Number" error. In order to convert the ' ' (blank) OFFICE_IDs into 0's, your insert statement will have to look like this:
INSERT INTO FUND_ACCOUNT (AID_YEAR, OFFICE_ID) SELECT AID_YEAR, decode(OFFICE_ID,' ',0,OFFICE_ID) FROM FUND_ACCOUNT2;
I have found that the order of your SQL statement parameters is also important and the order they are instantiated in your code, this worked in my case when using "Oracle Data Provider for .NET, Managed Driver".
var sql = "INSERT INTO table (param1, param2) VALUES (:param1, :param2)";
...
cmd.Parameters.Add(new OracleParameter("param2", Convert.ToInt32("100")));
cmd.Parameters.Add(new OracleParameter("param1", "alpha")); // This should be instantiated above param1.
Param1 was alpha and param2 was numeric, hence the "ORA-01722: invalid number" error message. Although the names clearly shows which parameter it is in the instantiation, the order is important. Make sure you instantiate in the order the SQL is defined.
For me this error was a bit complicated issue.
I was passing a collection of numbers (type t_numbers is table of number index by pls_integer;) to a stored procedure. In the stored proc there was a bug where numbers in this collection were compared to a varchar column
select ... where ... (exists (select null from table (i_coll) ic where ic.column_value = varchar_column))
Oracle should see that ic.column_value is integer so shouldn't be compared directly to varchar but it didn't (or there is trust for conversion routines).
Further complication is that the stored proc has debugging output, but this error came up before sp was executed (no debug output at all).
Furthermore, collections [<empty>] and [0] didn't give the error, but for example [1] errored out.
The ORA-01722 error is pretty straightforward. According to Tom Kyte:
We've attempted to either explicity or implicity convert a character string to a number and it is failing.
However, where the problem is is often not apparent at first. This page helped me to troubleshoot, find, and fix my problem. Hint: look for places where you are explicitly or implicitly converting a string to a number. (I had NVL(number_field, 'string') in my code.)
This happened to me too, but the problem was actually different: file encoding.
The file was correct, but the file encoding was wrong. It was generated by the export utility of SQL Server and I saved it as Unicode.
The file itself looked good in the text editor, but when I opened the *.bad file that the SQL*loader generated with the rejected lines, I saw it had bad characters between every original character. Then I though about the encoding.
I opened the original file with Notepad++ and converted it to ANSI, and everything loaded properly.
In my case it was an end of line problem, I fixed it with dos2unix command.
In my case I was trying to Execute below query, which caused the above error ( Note : cus_id is a NUMBER type column)
select *
from customer a
where a.cus_id IN ('115,116')
As a solution to the caused error, below code fragment(regex) can be used which is added in side IN clause (This is not memory consuming as well)
select *
from customer a
where a.cus_id IN (select regexp_substr (
com_value,
'[^,]+',
1,
level
) value
from (SELECT '115,116' com_value
FROM dual)rws
connect by level <=
length ( com_value ) - length ( replace ( com_value, ',' ) ) + 1)
try this as well, when you have a invalid number error
In this
a.emplid is number and b.emplid is an varchar2 so if you got to convert one of the sides
where to_char(a.emplid)=b.emplid
You can always use TO_NUMBER() function in order to remove this error.This can be included as INSERT INTO employees phone_number values(TO_NUMBER('0419 853 694');