Beginner in SQL i'm currently unable to run this insert basic command.
insert into Project(ProjId,MedicName,Purpose,Start_date,End_date,PI_Id)
insert into Project values('PR003','Medic3','lung','01-Nov-14','31-DEC-20','10101');
ERROR at line 2:
ORA-00926: missing VALUES keyword
Your syntax is wrong. You need to write one statement:
insert into Project(ProjId,MedicName,Purpose,Start_date,End_date,PI_Id)
values('PR003','Medic3','lung','01-Nov-14','31-DEC-20','10101');
Apart from the wrong syntax (you've already been told that), as it appears that certain columns in that table are DATE datatype, I'd suggest you not to enter strings into it, but dates. Becuase, both '01-Nov-14' and '31-DEC-20' are strings.
Don't rely on Oracle's implicit conversion. As long as it might work now, it'll fail sooner or later (when NLS settings change) not necessarily on this database, but on some other. For example, your values wouldn't fit into my database because my format is different, as well as language (we don't use English names). Take control over it.
You could
use date literal (which I used for start_date)
use TO_DATE function with appropriate format mask (end_date below)
Something like this:
INSERT INTO project (projid,
medicname,
purpose,
start_date,
end_date,
pi_id)
VALUES ('PR003',
'Medic3',
'lung',
DATE '2014-11-01', --> this
TO_DATE('31.12.2020', 'dd.mm.yyyy'), --> this
'10101');
Related
Creating a mySomeTable table with 2 fields
create table mySomeTable (
IDRQ VARCHAR2(32 CHAR),
PROCID VARCHAR2(64 CHAR)
);
Creating an index on the table by the PROCID field
create index idx_PROCID on mySomeTable(trunc(PROCID));
Inserting records:
insert into mySomeTable values ('a', '1'); -- OK
insert into mySomeTable values ('b', 'c'); -- FAIL
As you can see, an error has been made in the index construction script and the script will try to build an index on the field using the trunc() function.
trunct() is a function for working with dates or numbers, and the field has the string type
This index building script successfully works out and creates an index without displaying any warnings and errors.
An index is created on the table using the TRUNC(TO_NUMBER(PROCID)) function
When trying to insert or change an entry in the table, if PROCID cannot be converted to a number, I get the error ORA-01722: invalid number, which is actually logical.
However, the understanding that I am working in a table with rows and adding string values to the table, and the error is about converting to a number, was misleading and not understanding what is happening...
Question: Why does Oracle change the index construction function, instead of giving an error? And how can this be avoided in the future?
Oracle version 19.14
Naturally, there was only one solution - to create the right index with the right script
create index idx_PROCID on mySomeTable(PROCID);
however, this does not explain, to me, this Oracle behavior.
Oracle doesn't know if the index declaration is wrong or the column data type is wrong. Arguably (though some may well disagree!) Oracle shouldn't try to second-guess your intentions or enforce restrictions beyond those documented in the manual - that's what user-defined constraints are for. And, arguably, this index acts as a form of pseudo-constraint. That's a decision for the developer, not Oracle.
It's legal, if usually ill-advised, to store a number in a string column. If you actually intentionally chose to store numbers as strings - against best practice and possibly just to irritate future maintainers of your code - then the index behaviour is reasonable.
A counter-question is to ask where it should draw the line - if you expect it to error on your index expression, what about something like
create index idx_PROCID on mySomeTable(
case when regexp_like(PROCID, '^\d.?\d*$') then trunc(PROCID) end
);
or
create index idx_PROCID on mySomeTable(
trunc(to_number(PROCID default null on conversion error))
);
You might actually have chosen to store both numeric and non-numeric data in the same string column (again, I'm not advocating that) and an index like that might then useful - and you wouldn't want Oracle to prevent you from creating it.
Something that obviously doesn't make sense and shouldn't be allowed to you is much harder for software to evaluate.
Interestingly the documentation says:
Oracle recommends that you specify explicit conversions, rather than rely on implicit or automatic conversions, for these reasons:
...
If implicit data type conversion occurs in an index expression, then Oracle Database might not use the index because it is defined for the pre-conversion data type. This can have a negative impact on performance.
which is presumably why it actually chooses here to apply explicit conversion when it creates the index expression (which you can see in user_ind_expressions - fiddle)
But you'd get the same error if the index expression wasn't modified - there would still be an implicit conversion of 'c' to a number, and that would still throw ORA-01722. As would some strings that look like numbers if your NLS settings are incompatible.
I have problem with some thing input multiple date through prompt
my query something like
select something
from
something
where
to_date (bus.TDATE) not in (:didb1)
I want to input like '12-Jun-2016','11-Jun-2016'
i am doing php oracle,
My code following:
select bus.*,con.* from
BusinessPayment bus,
ConsumerPayment con
where bus.TDATE=con.TDATE
and to_date (bus.TDATE) not in (:didbv)
');
$bscode1='11-June-2016','10-June-2016','09-June-2016';
oci_bind_by_name($stid, ':didbv', $bscode1);
oci_execute($stid);
You can't use a single bind variable to represent a list of values in an in() clause. Bind variables don't contain multiple values; the value you bind is seen as a single string value. So you're effectively doing:
where
to_date (bus.TDATE) not in (q'['11-June-2016','10-June-2016','09-June-2016']')
If TDATE is already a date type - which it hopefully is, and the joins suggest it might be - then you should not be passing that through to_date() - you are doing an implicit conversion from date to string, then a semi-explicit conversion back to a date, both using your session's NLS_DATE_FORMAT. That is either doing unnecessary work, or losing resolution, depending on your format model and whether the dates have times. If the intention is to ignore the time part of the value then there are better ways to do that.
Anyway, since that is a date now whatever type it was before, the right had side of that filter will also be converted to a date, so you're doing:
where
to_date (bus.TDATE) not in (to_date(q'['11-June-2016','10-June-2016','09-June-2016']'))
... and it's that which is throwing the exception, whatever your NLS settings are. Even if you passed a single value it would error because of the embedded single quotes. You can replicate that with:
select to_date(q'['11-June-2016','10-June-2016','09-June-2016']') from dual;
which also gets ORA-01858: a non-numeric character was found where a numeric was expected.
Ideally you would pass the individual date strings as elements of an array, but you can also work around this with an XML hack. You can pass a single string containing comma-delimited values to XMLTable(), and it will split it in to rows:
select * from xmltable(q'['11-June-2016','10-June-2016','09-June-2016']');
COLUMN_VALUE
--------------------------------------------------------------------------------
11-June-2016
10-June-2016
09-June-2016
Then you can convert each of those values to a date:
select to_date(column_value, 'DD-Month-YYYY')
from xmltable(q'['11-June-2016','10-June-2016','09-June-2016']')
and use that in a subquery or a join:
select * from dual
where trunc(sysdate) not in (select to_date(column_value, 'DD-Month-YYYY')
from xmltable(q'['11-June-2016','10-June-2016','09-June-2016']'));
And that works with a string bind variable, so your code would be:
select bus.*,con.*
from BusinessPayment bus
join ConsumerPayment con
on bus.TDATE=con.TDATE
where bus.TDATE not in (select to_date(column_value, 'DD-Month-YYYY')
from xmltable(:didbv));
I've modified this to use ANSI join syntax, which isn't relevant but there's rarely a reason to use the ancient syntax you have. If TDATE does include the time you'll need to modify it a bit - truncating is simplest but might affect performance.
Or you could join:
select bus.*,con.*
from xmltable(:didbv) x
join BusinessPayment bus
on bus.TDATE >= to_date(x.column_value, 'DD-Month-YYYY')
and bus.TDATE < to_date(x.column_value, 'DD-Month-YYYY') + 1
join ConsumerPayment con
on bus.TDATE=con.TDATE
In this version TDATE can have a time, and it matches any time on the days specified in the bind variable.
It would be better to supply the dates in a format that doesn't have the month name in it, as that could give you problems when run in different sessions or locales. If you know the PHP side will always be English you could force that to be recognised:
on bus.TDATE >= to_date(x.column_value, 'DD-Month-YYYY', #NLS_DATE_LANGUAGE=ENGLISH')
but if you can change the PHP format to use month numbers, and change the Oracle format model to match, that would be a bit simpler.
I have an insert statement, where one of the inserted fields is date. I use to_date function to convert string to date in this way:
to_date('10-MAY-10', 'DD-MON-RR')
It works fine, but I found, that it allows also variants like:
to_date('10?MAY?10', 'DD-MON-RR')
to_date('10+MAY+10', 'DD-MON-RR')
I'm expecting an Oracle error, however it makes an insert. Could you please explain why or give a reference to relevant documentation?
Oracle will test for other formats if it fails to find a match in the string - you can see the rules for what it looks for here in the documentation.
As an aside, years have four digits. Please make sure you specify all four when you provide a date-as-a-string, where possible; it saves the database from having to guess and potentially getting it wrong. I.e. your original example should be:
to_date('10-05-2010', 'DD-MM-YYYY')
If you need to restrict the date-as-a-string to a specific format, you can use the fx format modifier, which is mentioned earlier in the same document I linked to previously.
eg. to_date('10/05/2010', 'dd-mm-yyyy') would match but to_date('10/05/2010', 'fxdd-mm-yyyy') would fail
I have the following piece of XML:
<per:Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.something.com/2014/11/bla/webservice.xsd"
xmlns:per="http://www.something.com/2014/11/bla/person">
<per:Initials>E.C.</per:Initials>
<per:FirstName>Erik</per:FirstName>
<per:LastName>Flipsen</per:LastName>
<per:BirthDate>1980-07-01</per:BirthDate>
<per:Gender>Male</per:Gender>
</per:Person>
From this xml I want to extract some data in PL/SQL. I'd like to use XMLTABLE, since the EXTRACT and EXTRACTVALUE functions are deprecated.
I am able to extract the data using this query:
select pers.Initials,
pers.Firstname
into lsInitials,
lsFirstname
from
XMLTABLE ('*:Person' passing pxRequest
columns Initials PATH '*:Initials',
Firstname PATH '*:FirstName'
) pers;
I'm using wildcards for the namespaces since I don't really care what abbreviations the sending party is using for the namespace, I know the exact path where to get my data anyway.
With this code I have two things that puzzle me:
According to the documentation on http://docs.oracle.com/database/121/SQLRF/functions268.htm#SQLRF06232 PATH should be optional, however, as soon as I remove the PATH from the COLUMNS section, I don't get any results anymore.
Edit:
I found out that when I remove the namespaces for the elements, and made them uppercase, it works. So it seems like the column names need to match the xml elements names to make it work. I didn't yet figure out how to make it work with namespaced XML.
The documentation also notes "For each resulting column except the FOR ORDINALITY column, you must specify the column data type", however, it seems to work fine without it. It also seems a bit redundant to specify it for the columns and for the variables I'm fetching the data into. Any idea if not specifying the data types could get me into trouble?
Runnable code sample:
SET SERVEROUTPUT ON;
DECLARE
pxRequest xmltype := xmltype('<per:Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.something.com/2014/11/bla/webservice.xsd"
xmlns:per="http://www.something.com/2014/11/bla/person">
<per:Initials>E.C.</per:Initials>
<per:FirstName>Erik</per:FirstName>
<per:LastName>Flipsen</per:LastName>
<per:BirthDate>1980-01-01</per:BirthDate>
<per:Gender>Male</per:Gender>
</per:Person>');
lsInitials varchar2(100);
lsFirstname varchar2(100);
begin
select pers.Initials,
pers.Firstname
into lsInitials,
lsFirstname
from
XMLTABLE ('*:Person' passing pxRequest
columns Initials PATH '*:Initials',
Firstname PATH '*:FirstName'
) pers;
dbms_output.put_line(lsInitials);
dbms_output.put_line(lsFirstname);
end;
As per your first question, the documentation you linked has this to day about omitting PATH:
The optional PATH clause specifies that the portion of the XQuery result that is addressed by XQuery expression string is to be used as the column content.
If you omit PATH, then the XQuery expression column is assumed. For example:
(... COLUMNS xyz)
is equivalent to
XMLTable(... COLUMNS xyz PATH 'XYZ')
You can use different PATH clauses to split the XQuery result into different virtual-table columns.
The reason the column xyz is assumed to be 'XYZ' is because Oracle, by default, is case insensitive (defaults to all-caps). If you had defined your column as "aBcD" then the PATH value will be assumed to be 'aBcD'
As for your second question about specifying data types: if the data you're extracting is always going to be text data, you might be able to get away with not specifying a data type.
However, if you start dealing with things like dates, timestamps, floating point numbers, etc, then you may run into issues. You'll either need to manually convert them using the TO_* functions or you can specify their data types in the column definitions. If you don't, Oracle is free to implicitly cast it however it feels fit, which may have unexpected consequences.
References:
https://stackoverflow.com/a/9976068/377141
How to parse xml by xmltable when using namespace in xml(Oracle)
It should work as expected if you load in the namespace elements in your xmltable:
select results
from xmltable(
xmlnamespaces(
default 'http://tempuri.org/',
'http://schemas.xmlsoap.org/soap/envelope/' as "soap"
),
'soap:Envelope/soap:Body/addResponse' passing xmltype(v_xml)
columns results varchar(100) path './addResult')
From your example (you may also need to register your schema/namespace ahead of time, but that should be once):
select pers.Initials,
pers.Firstname
into lsInitials,
lsFirstname
from
XMLTABLE (
xmlnamespaces(
default 'http://tempuri.org/',
'http://www.w3.org/2001/XMLSchema-instance' as "xsi",
'http://www.something.com/2014/11/bla/person' as "per"
),
passing pxRequest
columns Initials PATH '*:Initials',
Firstname PATH '*:FirstName'
) pers;
Things that used to work in previous versions of Oracle do not work in 11g+ with respect to XML, as from what I have seen, Oracle strongly verifies/types the input/output of XML operations where in previous versions you could run normal proper XQuery operations without namespace info.
I need to connect to oracle table and issue a select stament. When I do this:
SELECT T."Node" as LPAR, to_char(CAST((FROM_TZ(CAST(GET_UTC_TIMESTAMP(T."Timestamp", TMZDIFF) AS TIMESTAMP),'+00:00') AT TIME ZONE 'US/Eastern') AS DATE),'dd-Mon-yyyy hh24:mi') as DATETIME,T."MAX_Memory_Size_MB",T."MIN_Comp_Memory",T."AVG_Comp_Memory", T."MAX_Comp_Memory", T."MIN_Non_Comp_Memory", T."AVG_Non_Comp_Memory", "MAX_Non_Comp_Memory" FROM DW.KPX_PHYSICAL_MEMORY_DV T where t."Node" like 'server%'
it works, but the program I am using does not like double quotes around the column names e.g. T."Node".
I tried to rewrite this sql statment as below, but now I get invalid identifier.
Is there a way around this?
SELECT Node as LPAR, to_char(CAST((FROM_TZ(CAST(GET_UTC_TIMESTAMP(Timestamp, TMZDIFF) AS TIMESTAMP),'+00:00') AT TIME ZONE 'US/Eastern') AS DATE),'dd-Mon-yyyy hh24:mi') as DATETIME,MAX_Memory_Size_MB, MIN_Comp_Memory,AVG_Comp_Memory, MAX_Comp_Memory, MIN_Non_Comp_Memory, AVG_Non_Comp_Memory, MAX_Non_Comp_Memory FROM DW.KPX_PHYSICAL_MEMORY_DV where Node like 'server%'
If the first statement works, that indicates that you have created a case-sensitive column name. If you do that, you will have to use double-quotes around the identifier and specify the case correctly every single time you refer to the column. Creating a case-sensitive identifier is generally something that you should avoid at all costs.
If this is a new database object, the preferred solution would be to change the column name to be case-insensitive
ALTER TABLE DW.KPX_PHYSICAL_MEMORY_DV
RENAME COLUMN "Node" TO Node;
Another option would be to create a view on top of the table that exposes case-insensitive identifiers and to query that view rather than the base table. Of course, you'd also need to do that for all the other case-insensitive identifiers you reference in the query.