I tried to insert a sql query using esql code:
INSERT INTO Database.dbo.CUSTOMERS Values (9330,'Sai',7);
It is working fine but it was show error when it tried to insert code using xml format like:
INSERT INTO Database.dbo.CUSTOMERS(ID,NAME,AGE) Values (InputRoot.XMLNSC.emps.emp.id,InputRoot.XMLNSC.emps.emp.name,InputRoot.XMLNSC.emps.emp.age);
Then it was showing errors like BIP2230E, BIP2488E, BIP2321E.
If there is any connectivity problem means first insert command also should not work. Select also working fine.
Any suggestions to resolve problem?
It is fairly obvious that your paths (InputRoot.XMLNSC.emps.emp.id, etc ) do not exist under InputRoot.XMLNSC. You could easily check this using the debugger or (better) a Trace node.
To fix the problem, correct those paths.
You should also be declaring and using a REFERENCE variable, to make your ESQL more readable:
-- This is not the correct path, otherwise your code would be working already!
DECLARE refEmp REFERENCE to InputRoot.XMLNSC.emps.emp;
INSERT
INTO Database.dbo.CUSTOMERS(ID,NAME,AGE)
VALUES (refEmp.id,refEmp.name,refEmp.age)
Related
I am trying to run the following insert statement in an Influx shell:
insert test_overwrite,version=v5,channel=exchange-logs,account=NKI records=-523463,input_records=-53456 1675897200000000000;
I get the error:
ERR: {"error":"unable to parse [...] bad timestamp"}
I also tried to cast the numbers to integer like
insert test_overwrite,version=v5,channel=exchange-logs,account=NKI records=-523463i,input_records=-53456i 1675897200000000000;
but it also fails with bad timestamp error...
The measurement does not exist, and it should be created upon the first insert. This has worked out-of-the-box already in previous cases.
test_overwrite is the name of the measurement, version, channel and account are the tags and input_records, records are the fields. The last part is the timestamp.
Supposedly the syntax is
insert <measurement>,<comma separated tag_set with values> <comma separated field_set with values> <timestamp>
Not sure if it makes sense to include all I've tried, since they all fail with different reasons.
What's wrong with the syntax?
I am using Influx 1.8.2
I am trying to update fields of a table using a JSON_OBJECT_T's elements. However, I am getting
ORA-40573: Invalid use of PL/SQL JSON object type.
Example:
metadata := JSON_OBJECT_T.parse(json_clob)
insert into catimage (
OBJECTID,
OBJTYPE,
values(
sde.gdb_util.next_rowid('CISCAT', 'CATIMAGE'),
metadata.get_String('objtype'), --OBJTYPE
)
I don't get the error if I set each field I require from the JSON_OBJECT_T as a variable. Is that the only way?
Thank you.
Jon
The ORA issue has yet to be patched. Workaround as suggested by the article is to manually set all variables before insert.
It would have helped to view the table DDL and variable definition.
However, given the limited information shared in the question, you might be hitting a bug related to insertion of JSON objects using PLSQL.
The suggested workaround is to put the data into a string variable and inserting the data into table.
Hope it helps
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've tried a few different google searches but can't find any best practices or tutorials that address this.
This is the first time I've used a VS database project. I've imported an existing database (everything looks fine) and now I want to populate some of the tables post-deployment.
There is a Script.PostDeployment.sql file that includes the following header:
/*
Post-Deployment Script Template
--------------------------------------------------------------------------------------
This file contains SQL statements that will be appended to the build script.
Use SQLCMD syntax to include a file in the post-deployment script.
Example: :r .\myfile.sql
Use SQLCMD syntax to reference a variable in the post-deployment script.
Example: :setvar TableName MyTable
SELECT * FROM [$(TableName)]
--------------------------------------------------------------------------------------
*/
I'm wondering if from the last three lines there is some expected way to write these scripts using variables instead of just pure T-SQL syntax?
Should I be writing
INSERT INTO [dbo].[BlackAdder] VALUES ('edmund')
INSERT INTO [dbo].[BlackAdder] VALUES ('baldrick')
or
setvar [dbo].[BlackAdder] BlackAdder
INSERT INTO [$(BlackAdder)] VALUES ('edmund')
INSERT INTO [$(BlackAdder)] VALUES ('baldrick')
Does the latter allow some sort of compile-time check so that if setvar cannot resolve [dbo].[BlackAdder] that the project will give me some error?
If you open the project Properties folder, and click on Database.sqlcmvars you will see 3 vars already defined $(DefaultDataPath), $(DtabaseName) and $(DefaultLogPath) and can define your own here.
The setvar would be the other way around:
:setvar BlackAdder [dbo].[BlackAdder]
but ideally you define these in Database.sqlcmvars.
The intended use is for deploying your database project into multiple environments by defining SQLCMD variables and including them in your pre-deployment and post-deployment scripts.
How to: Define Variables for Database Projects
Property Files in Database and Server Projects
<-------PeopleCode------>
Hi,
I have a SQL query that i have tried executing using both SQLEXEC and SQL.fetch() but the problem is, when I am passing the values to parameters (:1,:2...) it does not return a row but when I hardcode the values in the where clause of the query itself, it retrieves the correct value.
Can anybody help?
My query looks similar to the following sample query :
Select * from PS_rec1 where emplid=:1 and plan_type=:2
it returns no data till i hardcode the values.
I have checked the values at the back end and some data is there to be fetched. Moreover, the same query retrieves data when ran in TOAD.
Have you tried outputting your binds to a log file just before you use them in your SQL statement?
If the binds aren't working, but literals are, then perhaps your binds don't contain the values that you expect them to.
You could also try explicitly setting the binds to the values that you're expecting just before the SQL statement. This will prove that the way you're passing in the binds is working correctly.
It required another update to the same record to get the values fetched in SQL exec.
M not sure what was the problem but i guess it might be that the previous update did not write the changes to the db even after an explicit commit.
Ok, you need to put your exact SQLExec statement in the question.
But, do you really have "Select * ..." in a SQLExec? How many columns are in your table? Since you mention the where clause, is your statement
SQLExec("select * from PS_rec where emplid=:1 and plan_type=:2", &var1, &var2, &vartocontainthewholerow);
Which will work in a SQL tool (toad) but probably does not work in AE or any type of Peoplecode program.
Now if your table has three columns, should you not have something like this:
SQLExec("select emplid, plan_type, column3 from PS_rec where emplid = :1 and plan_type=:2", &emplidIn, &plan_typeIn, &emplidOut, &plan_typeOut, &column3Out);
Notice that with three columns in the table that emplid and plan_type are two of them, you need to list all the columns you want, not asterisks '*'. Kind of silly to select the emplid and plan_type though.