import array type into hana? - sql
I am importing data into SAP HANA using the CSV files.
When I try to import a column which has an array type then it results in the following error
ARRAY type is not compatible with PARAMETER TYPE
For example
CREATE COLUMN TABLE "SCHEMA"."TABLE"
( 'ID' INT,
'SUBJECTS' INT ARRAY)
The above query creates the table and when I run
INSERT INTO "SCHEMA"."TABLE" VALUES (1,ARRAY(1,2,3))
It inserts successfully into the HANA database.
But when I try
INSERT INTO "SCHEMA"."TABLE" VALUES (1,"{1,2,3}")
It does not work.So how can I import the array values in the CSV file to the column in HANA database.
Array storage types can currently only be created by using the ARRAY() function.
You could construct the INSERT statement in a loop but you still need to construct the ARRAY() call for every record.
Ok, here's the example you asked for.
By now you should understand that there is no simple IMPORT command that would automatically insert arrays into a HANA table.
That leaves you with two options as I see it:
you write a loader program that reads your CSV file and parses
the array data {..., ... , ...} and makes INSERT statements with
ARRAY functions out of it.
or
You load the data in two steps:
2.1 Load the data from the CSV as-is and put the array data into a CLOB column.
2.2. Add the array columns to the table and run a loop that takes the CLOB data, replaces the curly brackets with normal brackets and creates a dynamic SQL statement.
Like so:
create column table array_imp_demo as (
select owner_name , object_type, to_clob( '{'|| string_agg ( object_oid, ', ') || '}' )array_text
from ownership
group by owner_name, object_type);
select top 10 * from array_imp_demo;
/*
OWNER_NAME OBJECT_TYPE ARRAY_TEXT
SYS TABLE {142540, 142631, 142262, 133562, 185300, 142388, 133718, 142872, 133267, 133913, 134330, 143063, 133386, 134042, 142097, 142556, 142688, 142284, 133577, 185357, 142409, 133745, 142902, 133308, 133948, 134359, 143099, 133411, 134135, 142118, 142578, 142762, 142306, 133604, 142429, 133764, 142928, 133322, 133966, 134383, 143120, 133443, 134193, 142151, 142587, 142780, 142327, 133642, 142448, 133805, 142967, 185407, 133334, 133988, 134624, 143134, 133455, 134205, 142173, 142510, 142606, 142798, 142236, 133523, 142359, 133663, 142465, 133825, 142832, 133175, 133866, 134269, 143005, 133354, 134012, 134646, 143148, 133497, 134231, 142195, 142526, 142628, 142816, 142259, 133551, 142382, 133700, 142493, 133855, 142862, 133235, 133904, 134309, 143051, 133373, 134029, 142082, 143306, 133513, 134255, 142216, 142553, 142684, 142281, 133572, 185330, 142394, 133738, 142892, 133299, 133929, 134351, 143080, 133406, 134117, 142115, 142576, 142711, 142303, 133596, 142414, 133756, 142922, 185399, 133319, 133958, 134368, 143115,
SYSTEM TABLE {154821, 146065, 146057, 173960, 174000, 173983, 144132, 173970}
_SYS_STATISTICS TABLE {151968, 146993, 147245, 152026, 147057, 147023, 151822, 147175, 147206, 151275, 151903, 147198, 147241, 151326, 151798, 152010, 147016, 147039, 147068, 151804, 151810, 147002, 147202, 151264, 151850, 147186, 147114, 147228, 151300, 151792, 151992, 147030, 147062, 151840, 147181, 147210, 151289, 151754, 149419, 150274, 147791, 150574, 147992, 149721, 150672, 148132, 149894, 147042, 148434, 149059, 150071, 147518, 148687, 149271, 150221, 150877, 147716, 148913, 150388, 147957, 149675, 150634, 148102, 149829, 148267, 148979, 149976, 147494, 148663, 151107, 149224, 150178, 147667, 148855, 149532, 150306, 147925, 149602, 150598, 148080, 149792, 148179, 149926, 147417, 148547, 149186, 150107, 147568, 148804}
_SYS_EPM TABLE {143391, 143427, 143354, 143385, 143411, 143376, 143398, 143367, 143414, 143344, 175755}
_SYS_REPO TABLE {145086, 151368, 171680, 145095, 152081, 169183, 151443, 149941, 154366, 143985, 145116, 152104, 151496, 169029, 177728, 179047, 145065, 169760, 178767, 151659, 169112, 169258, 153736, 177757, 174923, 145074, 150726, 151697, 169133, 178956, 145083, 169171, 168992, 145092, 177665, 169178, 151378, 169271, 178881, 174911, 154128, 143980, 145101, 152098, 151481, 177720, 152504, 145062, 151570, 169102, 154058, 145071, 170733, 151687, 169130, 145080, 171629, 169166, 178846, 145089, 149588, 151373, 177614, 143976, 145098, 152087, 151458, 149955, 178907, 154386, 145059, 169605, 151529, 169035, 178579, 151176, 179178, 145068, 150709, 151670, 169124, 174905, 177778, 154244, 145077, 170883, 169158, 144072, 152681, 144285, 154415, 144620, 145268, 168884, 144895, 143512, 151428, 168774, 143750, 152337, 168558, 144114, 149559, 152719, 144327, 144674, 145508, 168924, 144939, 143578, 152135, 143793, 152392, 168587, 144151, 152753, 144370, 144720, 145722, 168960, 144990, 143626, 152174, 143832, 152435, 168620, 144188, 152785,
_SYS_TASK TABLE {146851, 146847, 146856, 146231, 146143, 146839, 146854, 146834, 146430, 146464, 146167, 146505, 146205, 146257, 146384, 146313, 146420, 146356, 146454, 146155, 146495, 146193, 146525, 146244, 146368, 146296, 146410, 146346, 146443, 146148, 146484, 146181, 146517, 146234, 146275, 146395, 146325}
_SYS_AFL TABLE {177209, 176741, 176522, 177243, 176777, 176692, 176201, 177294, 176929, 177328, 176967, 177383, 177105, 177015, 176826, 177143, 177056, 176866, 177215, 176748, 176550, 176474, 177249, 176784, 176699, 176218, 146871, 177300, 176935, 177335, 176973, 177389, 177111, 177021, 176835, 177156, 177062, 176883, 185427, 177221, 176755, 176572, 176487, 177261, 176790, 176706, 176398, 177306, 176941, 177341, 176979, 177397, 177119, 177033, 176843, 177162, 177069, 176889, 177228, 176762, 176589, 177267, 176799, 176713, 176416, 177313, 176953, 177348, 176991, 177404, 177127, 177040, 176849, 177173, 177075, 176895, 177195, 176732, 176507, 177234, 176768, 177274, 176805, 176720, 176448, 177285, 176921, 177319, 176959, 177354, 176997, 177375, 177095, 177007, 176818, 177411, 177133, 177047, 176858, 177179, 177081, 176911, 177201, 176738, 176519, 177241, 176775, 176690, 176196, 177280, 176814, 176727, 176464, 177291, 176927, 177326, 176965, 177360, 177003, 177381, 177103, 177013, 176824, 177141, 177053, 176864, 177191, 177091,
_SYS_XB TABLE {146971, 146957}
DEVDUDE TABLE {167121, 165374, 182658, 156616, 173111, 181568, 174901, 183413, 184432, 183498, 183470, 184464, 155821, 173102, 183613, 184495, 155857, 166744, 180454, 184547, 156234, 172096, 166765, 165548, 184649, 183399, 184357, 184577, 183477, 181594, 183537, 181572, 167201, 184685, 185467, 183406, 184422, 184610, 183491, 155842, 172923, 157723, 182636, 167895, 183463, 184454, 183505, 165542, 183606, 184488, 155849, 172749, 157626, 184527, 183449, 166759, 184627, 182827, 184347, 184568, 157619, 172118, 183530, 181556, 167137, 184670, 182642, 184411, 184598, 183484, 155835, 183456, 183593, 181584, 167328, 183421, 184443, 183586, 184474, 155828, 166392, 183620, 184517, 183435, 183442, 183512, 166753, 184557, 156598, 172106, 183523, 166771, 166568, 184660, 182630, 184381, 184587, 183428, 157681, 182649, 167264, 168236}
ADMIN TABLE {158520, 158925, 158982, 158492, 158571, 158583, 158560, 158541, 158744}
*/
Ok, let's just assume that this is the data that you managed to load from your CSV file into a table and that the ARRAY_DATA column is a big CLOB.
Now, the data is in the table, but you need to put it into an ARRAY column.
alter table array_imp_demo add (array_data integer array);
The unconvenient part follows now: creating a new UPDATE command for each record to transform the CLOB data into a proper ARRAY() function call.
Be aware that this update command works correctly, because (OWNER, OBJECT_TYPE) are used as keys in this case.
do begin
declare vsqlmain nvarchar (50) :='UPDATE array_imp_demo set array_data = ARRAY ';
declare vsql nvarchar(5000);
declare cursor c_upd for
select OWNER_NAME, OBJECT_TYPE,
replace (replace (ARRAY_TEXT, '{', '(' ), '}', ')' ) array_data
from array_imp_demo;
for cur_row as c_upd do
vsql = :vsqlmain || cur_row.array_data;
vsql = :vsql || ' WHERE owner_name = ''' || cur_row.owner_name || '''';
vsql = :vsql || ' AND object_type = ''' || cur_row.object_type || '''';
exec :vsql;
end for;
end;
select * from array_imp_demo;
OWNER_NAME OBJECT_TYPE ARRAY_TEXT ARRAY_DATA
SYS TABLE {142540, 142631, 142262,... 142540, 142631, 142262,...
SYSTEM TABLE {154821, 146065, 146057,... 154821, 146065, 146057,...
_SYS_STATISTICS TABLE {151968, 146993, 147245,... 151968, 146993, 147245,...
_SYS_EPM TABLE {143391, 143427, 143354,... 143391, 143427, 143354,...
_SYS_REPO TABLE {145086, 151368, 171680,... 145086, 151368, 171680,...
After that you can drop the CLOB column.
Ok, that's about it from my side.
Have you tried using CTL method to import data. I hope that might help.
Related
Oracle SQL - table type in cursor causing ORA-21700: object does not exist or is marked for delete
I have problem with my function, I'm getting ORA-21700: object does not exist or is marked for delete error. It's caused by table type parameter in cursor, but I've no idea how to fix it. I've read that table type part should be assigned to a variable, but it can't be done in cursor, right? I've marked the part which causing the issue Can anyone help? Is there any other way I can do this? My package looks something like this: FUNCTION createCSV(DateFrom date ,DateTo date) RETURN clob IS CURSOR c_id (c_DateFrom date ,c_DateTo date) IS SELECT id FROM limits WHERE utcDateFrom <= NVL(c_DateTo, utcDateFrom) AND NVL(utcDateTo, c_DateFrom + 1) >= c_DateFrom + 1; CURSOR c (c_DateFrom date ,c_DateTo date ,pc_tDatePeriods test_pkg.t_date_periods) IS -- this is table type (TYPE xx AS TABLE OF records) SELECT l.id limit_id ,TO_CHAR(time_cond.utcDateFrom, og_domain.cm_yyyymmddhh24mi) time_stamp_from ,TO_CHAR(time_cond.utcDateTo, og_domain.cm_yyyymmddhh24mi) time_stamp_to FROM limits l JOIN (SELECT limit_id, utcDateFrom, utcDateTo FROM TABLE(pc_tDatePeriods) --This part is causing the issue ) time_cond ON l.id = time_cond.limit_id WHERE l.utcDateFrom <= NVL(c_DateTo, l.utcDateFrom) AND NVL(l.utcDateTo, c_DateFrom + 1) >= c_DateFrom + 1; CSV clob; tDatePeriods test_pkg.t_date_periods := test_pkg.t_date_periods(); BEGIN FOR r_id IN c_id(DateFrom, DateTo) LOOP tDatePeriods := test_pkg.includeTimeGaps(p_Id => r_id.id); --this loop is ok FOR r IN c(DateFrom, DateTo, tDatePeriods) --here I'm getting error LOOP CSV := CSV || chr(13) || r.limit_id || ',' || r.time_stamp_from || ',' || r.time_stamp_to; END LOOP; END LOOP; RETURN CSV; END createCSV;
Your problem should be solved by declaring type test_pkg.t_date_periods on schema level instead of in package. Similar answer can be found here but with more details.
How to Insert data using cursor into new table having single column containing XML type data in Oracle?
I'm able to insert values into table 2 from table 1 and execute the PL/SQL procedure successfully but somehow the output is clunky. I don't know why?
Below is the code :
create table airports_2_xml
(
airport xmltype
);
declare
cursor insert_xml_cr is select * from airports_1_orcl;
begin
for i in insert_xml_cr
loop
insert into airports_2_xml values
(
xmlelement("OneAirport",
xmlelement("Rank", i.Rank) ||
xmlelement("airport",i.airport) ||
xmlelement("Location",i.Location) ||
xmlelement("Country", i.Country) ||
xmlelement("Code_iata",i.code_iata) ||
xmlelement("Code_icao", i.code_icao) ||
xmlelement("Total_Passenger",i.Total_Passenger) ||
xmlelement("Rank_change", i.Rank_change) ||
xmlelement("Percent_Change", i.Percent_change)
));
end loop;
end;
/
select * from airports_2_xml;
Output:
Why it is showing < ,> in the output ? And why am I unable to see the output fully?
Expected output:
<OneAirport>
<Rank>3</Rank>
<Airport>Dubai International</Airport>
<Location>Garhoud</Location>
<Country>United Arab Emirates</Country>
<Code_IATA>DXB</Code_IATA>
<Code_ICAO>OMDB</Code_ICAO>
<Total_passenger>88242099</Total_passenger>
<Rank_change>0</Rank_change>
<Percent_Change>5.5</Percent_Change>
</OneAirport>
The main issue is how you are constructnig the XML. You have an outer XMLElement for OneAirport, and the content of that element is a single string.
You are generating individual XMLElements from the cursor fields, but then you are concenating those together, which gives you a single string which still has the angle brackets you're expecting. So you're trying to do something like, simplified a bit:
select
xmlelement("OneAirport", '<Rank>1</Rank><airport>Hartsfield-Jackson</airport>')
from dual;
XMLELEMENT("ONEAIRPORT",'<RANK>1</RANK><AIRPORT>HARTSFIELD-JACKSON</AIRPORT>')
--------------------------------------------------------------------------------
<OneAirport><Rank>1</Rank><airport>Hartsfield-Jackson</airp
and by default XMLElement() escapes entities in the passed-in values, so the angle-brackets are being converted to 'safe' equivalents like <. If it didn't do that, or you told it not to with noentityescaping:
select xmlelement(noentityescaping "OneAirport", '<Rank>1</Rank><airport>Hartsfield-Jackson</airport>')
from dual;
XMLELEMENT(NOENTITYESCAPING"ONEAIRPORT",'<RANK>1</RANK><AIRPORT>HARTSFIELD-JACKS
--------------------------------------------------------------------------------
<OneAirport><Rank>1</Rank><airport>Hartsfield-Jackson</airport></OneAirport>
then that would appear to be better, but you still actually have a single element with a single string (with characters that are likely to cause problems down the line), rather than the XML structure you almost certainly intended.
A simple way to get an zctual structure is with XMLForest():
xmlelement("OneAirport",
xmlforest(i.Rank, i.airport, i.Location, i.Country, i.code_iata,
i.code_icao, i.Total_Passenger, i.Rank_change, i.Percent_change)
)
You don't need the cursor loop, or any PL/SQL; you can just do:
insert into airports_2_xml (airport)
select xmlelement("OneAirport",
xmlforest(i.Rank, i.airport, i.Location, i.Country, i.code_iata,
i.code_icao, i.Total_Passenger, i.Rank_change, i.Percent_change)
)
from airports_1_orcl i;
The secondary issue is the display. You'll see more data if you issue some formatting commands, such as:
set lines 120
set long 32767
set longchunk 32767
Those will tell your client to retrieve and show more of the long (XMLType here) data, rather the default 80 characters it's giving you now.
Once you are generating a nested XML structure you can use XMLSerialize() to display that more readable when you query your second table.
Try this below block : declare cursor insert_xml_cr is select * from airports_1_orcl; v_airport_xml SYS.XMLTYPE; begin for i in insert_xml_cr loop SELECT XMLELEMENT ( "OneAirport", XMLFOREST(i.Rank as "Rank" ,i.airport as "Airport" ,i.Location as "Location" ,i.Country as "Country" ,i.code_iata as "Code_iata" ,i.code_icao as "code_icao" ,i.Total_Passenger as "Total_Passenger" , i.Rank_change as "Rank_change" ,i.Percent_change as "Percent_Change" )) into v_airport_xml FROM DUAL; insert into airports_2_xml values (v_airport_xml); end loop; end;
Dropping a list of tables with schemas specified in postgreSQL
I've read the documentation on this here so I'm 90% sure, but the docs don't explicitly say if there's a limit to the list size, or if lists can also have schema names in the name formatting. I just want to be positive before I accidentally mess up my database or delete everything in a way I can't recover. To drop a large list of tables (nearly 200) in postgreSQL, is the SQL command: DROP TABLE schemaA.table_name, schemaB.tableA_name, schemaC.table_name, schemaC.tableB_name; Would appreciate if someone could confirm. Thanks!
You should be ok with 200 table list with schemas. Also wrap up drop to transaction if you have doubts. Postgres supports DDL in transactions. Below is my successful run...
prepare:
t=# create table so(i int);
CREATE TABLE
t=# do $$ begin for i in 1..200 loop execute 'create table sol'||i||' as select 8 from so where false'; end loop; end; $$;
DO
select string_agg('public.'||tablename, ', ') from pg_tables where tablename like 'sol%';
run:
t=# drop table public.sol3, public.sol4, public.sol5, public.sol6, public.sol7, public.sol8, public.sol9, public.sol10, public.sol1, public.sol2, public.sol11, public.sol12, public.sol13, public.sol14, public.sol15, public.sol16, public.sol17, public.sol18, public.sol19, public.sol20, public.sol21, public.sol22, public.sol23, public.sol24, public.sol25, public.sol26, public.sol27, public.sol28, public.sol29, public.sol46, public.sol47, public.sol30, public.sol31, public.sol32, public.sol33, public.sol34, public.sol35, public.sol36, public.sol37, public.sol38, public.sol39, public.sol40, public.sol41, public.sol42, public.sol43, public.sol44, public.sol45, public.sol48, public.sol49, public.sol50, public.sol51, public.sol52, public.sol53, public.sol54, public.sol55, public.sol56, public.sol57, public.sol58, public.sol59, public.sol60, public.sol61, public.sol62, public.sol63, public.sol64, public.sol65, public.sol66, public.sol67, public.sol68, public.sol69, public.sol70, public.sol71, public.sol72, public.sol73, public.sol74, public.sol75, public.sol76, public.sol77, public.sol78, public.sol79, public.sol80, public.sol81, public.sol82, public.sol83, public.sol84, public.sol85, public.sol86, public.sol87, public.sol88, public.sol89, public.sol90, public.sol91, public.sol92, public.sol93, public.sol94, public.sol95, public.sol96, public.sol97, public.sol98, public.sol99, public.sol100, public.sol101, public.sol102, public.sol103, public.sol104, public.sol105, public.sol106, public.sol107, public.sol108, public.sol109, public.sol110, public.sol111, public.sol112, public.sol113, public.sol114, public.sol115, public.sol116, public.sol117, public.sol118, public.sol119, public.sol120, public.sol121, public.sol122, public.sol123, public.sol124, public.sol125, public.sol126, public.sol127, public.sol128, public.sol129, public.sol130, public.sol131, public.sol132, public.sol133, public.sol134, public.sol135, public.sol136, public.sol137, public.sol138, public.sol139, public.sol140, public.sol141, public.sol142, public.sol143, public.sol144, public.sol145, public.sol146, public.sol147, public.sol148, public.sol149, public.sol150, public.sol151, public.sol152, public.sol153, public.sol154, public.sol155, public.sol156, public.sol157, public.sol158, public.sol159, public.sol160, public.sol161, public.sol162, public.sol163, public.sol164, public.sol165, public.sol166, public.sol167, public.sol168, public.sol169, public.sol170, public.sol171, public.sol172, public.sol173, public.sol174, public.sol175, public.sol176, public.sol177, public.sol178, public.sol179, public.sol180, public.sol181, public.sol182, public.sol183, public.sol184, public.sol185, public.sol186, public.sol187, public.sol188, public.sol189, public.sol190, public.sol191, public.sol192, public.sol193, public.sol194, public.sol195, public.sol196, public.sol197, public.sol198, public.sol199, public.sol200;
DROP TABLE
check:
t=# select string_agg('public.'||tablename, ', ') from pg_tables where tablename like 'sol%'; string_agg
------------
(1 row)
How to call Oracle MD5 hash function?
I have below code. I am using Oracle 11g. SELECT DBMS_OBFUSCATION_TOOLKIT.md5 (input => UTL_RAW.cast_to_raw( FIRST_NAME ||LAST_NAME )) md5_key , FIRST_NAME , LAST_NAME FROM C_NAME_TAB WHERE PKEY='1234' How can i call this code? Can i directly execute this code in sqldeveloper?
In Oracle 12c you can use the function STANDARD_HASH. It does not require any additional privileges.
select standard_hash('foo', 'MD5') from dual;
The dbms_obfuscation_toolkit is deprecated (see Note here). You can use DBMS_CRYPTO directly:
select rawtohex(
DBMS_CRYPTO.Hash (
UTL_I18N.STRING_TO_RAW ('foo', 'AL32UTF8'),
2)
) from dual;
Output:
ACBD18DB4CC2F85CEDEF654FCCC4A4D8
Add a lower function call if needed. More on DBMS_CRYPTO.
I would do:
select DBMS_CRYPTO.HASH(rawtohex('foo') ,2) from dual;
output:
DBMS_CRYPTO.HASH(RAWTOHEX('FOO'),2)
--------------------------------------------------------------------------------
ACBD18DB4CC2F85CEDEF654FCCC4A4D8
#user755806 I do not believe that your question was answered. I took your code but used the 'foo' example string, added a lower function and also found the length of the hash returned. In sqlplus or Oracle's sql developer Java database client you can use this to call the md5sum of a value. The column formats clean up the presentation.
column hash_key format a34;
column hash_key_len format 999999;
select dbms_obfuscation_toolkit.md5(
input => UTL_RAW.cast_to_raw('foo')) as hash_key,
length(dbms_obfuscation_toolkit.md5(
input => UTL_RAW.cast_to_raw('foo'))) as hash_key_len
from dual;
The result set
HASH_KEY HASH_KEY_LEN
---------------------------------- ------------
acbd18db4cc2f85cedef654fccc4a4d8 32
is the same value that is returned from a Linux md5sum command.
echo -n foo | md5sum
acbd18db4cc2f85cedef654fccc4a4d8 -
Yes you can call or execute the sql statement directly in sqlplus or sql developer. I tested the sql statement in both clients against 11g.
You can use any C, C#, Java or other programming language that can send a statement to the database. It is the database on the other end of the call that needs to be able to understand the sql statement. In the case of 11 g, the code will work.
#tbone provides an excellent warning about the deprecation of the dbms_obfuscation_toolkit. However, that does not mean your code is unusable in 12c. It will work but you will want to eventually switch to dbms_crypto package. dbms_crypto is not available in my version of 11g.
To calculate MD5 hash of CLOB content field with my desired encoding without implicitly recoding content to AL32UTF8, I've used this code: create or replace function clob2blob(AClob CLOB) return BLOB is Result BLOB; o1 integer; o2 integer; c integer; w integer; begin o1 := 1; o2 := 1; c := 0; w := 0; DBMS_LOB.CreateTemporary(Result, true); DBMS_LOB.ConvertToBlob(Result, AClob, length(AClob), o1, o2, 0, c, w); return(Result); end clob2blob; / update my_table t set t.hash = (rawtohex(DBMS_CRYPTO.Hash(clob2blob(t.content),2)));
Why am I getting PLS - 00382?
Here is my object def:
CREATE OR REPLACE TYPE FALCON.contacts AS OBJECT (phone VARCHAR2(50)
,phoneusage VARCHAR2(25)
,phonetype VARCHAR2(25)
,email VARCHAR2(150)
,phoneext VARCHAR2(25)
,anytext VARCHAR2(250))
Here is the table def:
CREATE OR REPLACE TYPE FALCON.contacttbl AS TABLE OF contacts
Here is my pipelined function
FUNCTION get_pcontacts(p_conttbl IN xmltypedefs_spec.conttbl)
RETURN falcon.contacttbl
PIPELINED
IS
l_contact falcon.contacts;
BEGIN
FOR n IN 1 .. p_conttbl.count
LOOP
PIPE ROW(**falcon.contacts**(p_conttbl(n).phone, p_conttbl(n).phoneusage, p_conttbl(n).phonetype, p_conttbl(n).email, p_conttbl(n).phoneext, p_conttbl(n).anytext));
END LOOP;
RETURN;
END get_pcontacts;
I am getting the error when I call the table function here:
FUNCTION get_pidxml(p_pidrec xmltypedefs_spec.pidtyp)
RETURN CLOB
IS
l_tmprec CLOB;
l_pxml xmltype;
l_bxml xmltype;
l_pcontacts xmltypedefs_spec.conttbl := p_pidrec.personalcont;
l_bcontacts xmltypedefs_spec.conttbl := p_pidrec.businesscont;
BEGIN
-- l_pxml := get_contacts(p_pidrec, 'p');
-- l_bxml := get_contacts(p_pidrec, 'b');
SELECT xmlelement("pid"
,xmlforest(p_pidrec.setid AS "setID"
,p_pidrec.patidexternal AS "patientIDExternal"
,p_pidrec.patientid AS "patientID"
,p_pidrec.patintasgnauth AS "patientIDInterAssignAuthority"
,p_pidrec.patinttypecd AS "patientIDInternalIDTypeCode"
,p_pidrec.patidalternate1 AS "patientIDAlernate1"
,p_pidrec.patlastname AS "patientLastName"
,p_pidrec.patfirstname AS "patientFirstName"
,p_pidrec.patmiddleinit AS "patientMiddleInitial"
,p_pidrec.patsuffix AS "patientSuffix"
,p_pidrec.patprefix AS "patientPrefix"
,p_pidrec.degree AS "degree"
,p_pidrec.familyname AS "familyName"
,p_pidrec.givenname AS "givenName"
,p_pidrec.mothermaidname AS "mothersMaidenName"
,p_pidrec.dob AS "dateOfBirth"
,p_pidrec.adminsex AS "administrativeSex"
,p_pidrec.patientalias AS "patientAlias"
,p_pidrec.race AS "race"
,p_pidrec.racetext AS "raceText"
,p_pidrec.pataddr1 AS "patientAddress1"
,p_pidrec.pataddr2 AS "patientAddress2"
,p_pidrec.patcity AS "patientCity"
,p_pidrec.patstate AS "patientState"
,p_pidrec.patzip AS "patientZip"
,p_pidrec.countrycode AS "countryCode"
,p_pidrec.addresstype AS "addressType"
,p_pidrec.othgeodesig AS "otherGeographicDesignation"
,p_pidrec.county AS "county"
,(SELECT xmlagg(xmlelement("contactInfo",
xmlforest(phone AS "phoneNumber",
phoneusage AS "telecomUseCode",
phonetype AS "telecomequiptype",
email AS "email",
phoneext AS "phonenumberextension",
anytext AS "anytext")))
FROM TABLE(**get_pcontacts(l_pcontacts**))) AS "personalContact"
http://pls-00382.ora-code.com/
PLS-00382: expression is of wrong type
Since I don't know how xmltypedefs_spec.conttbl is defined, I removed the input parameter from the pipelined function and just had it generate fake data on the fly:
CREATE OR REPLACE FUNCTION get_contacts
RETURN contacttbl PIPELINED
IS
-- converts some structure to pipe of contacts
BEGIN
FOR n IN 1 .. 5 LOOP
PIPE ROW(
contact(
'877-867-5309',
'Work',
'Cell',
'jenny#gmail.com',
n,
'WTF?'
)
);
END LOOP;
RETURN;
END get_contacts;
The subquery now executes without error:
SELECT
xmlagg(
xmlelement("contactInfo",
xmlforest(
phone AS "phoneNumber",
phoneusage AS "telecomUseCode",
phonetype AS "telecomequiptype",
email AS "email",
phoneext AS "phonenumberextension",
anytext AS "anytext"
)
)
)
FROM
TABLE( get_contacts( ) )
This tells me there is probably something wrong with xmltypedefs_spec.conttbl, perhaps in using a collection type within an SQL statement? Not sure. What if you changed xmltypedefs_spec.pidtyp to use the falcon.contacttbl instead of xmltypedefs_spec.conttbl. Seems like you've got one package type and one object type that are doing the same thing?
xmltypedefs_spec defines record types that correspond to XML elements. These record types are used to shred and build XML. Originally, the XML did not use repeating elements, but now must. I am attempting to take a table of xmltypedefs_spec.pidtyp and use the pipelined function to return 'rows' of data from an associative table. It is in this fashion that I want to send rows of array records to build xml.