Unnesting XML and memory tables
Post Author: Guy Jeffery
CA Forum: Data Integration
Hi,
I'm having issues with unnesting incoming XML messages within a real time job. The XML is being partially unnested into intermediate memory tables, and the intermediate memory tables are used to populate physical database tables. This works fine on a small scale - if I only have a few physical tables to populate, it works as planned. However, when I increase the complexity of the job, the job will begin to execute and then just stop and 'hang'. There are no error messages, and the log for that job has a blue tick next to it - but the job never completes.
I've had a look through the technical help file with BODI, and searched this forum, but can't find anything which mentions the situation above. Is it likely to be a memory issue? Or is there some upper limit on the number of objects used within a real time BODI job?
Has anyone experienced these issues before, and found a resolution? Any suggestions would be greatly appeciated, as I need a solution pretty urgently. Thanks in advance.
Guy
Post Author: bhofmans
CA Forum: Data Integration
Guy,
In real-time jobs, the whole job is executed in one al_engine process, this includes all data processing, but also the memory tables. It's started once and stays active the whole time to treat incoming messages.
This is different for batch jobs where each data flow is a seperate process, and data flows are started in series or parallel depending on the job design, once finished processing they disappear again.
So for your real-time job this means the whole processing can only use a maximum of 2 GB of memory (upper limit for 32-bit processes). Upgrading to DI 11.7 would give you more options like using pageable cache which will use disk space as additional memory to overcome the 2 GB limitation. But the first thing to check would be the amount of memory used - I'm just assuming here you need more then 2 GB, you can easily check this via the Windows task manager. Which DI versions are you using ? Is this on Windows ?
- Ben.
Similar Messages
-
Is it possible to select from a PL/SQL in-memory table (Not a DB table or temp table) into an XML document? And to parse an XML document into a PL/SQL table?
What do you mean by in-memory table?
-
How to extract data from xml and insert into Oracle table
Hi,
I have a large xml file. which will have hundreds of the following transaction tags having column names and there values.
There is a table one of the schema with coulums "actualCostRate","billRate"....etc.
I need to extract the values of these columns and insert into the table
<Transaction actualCostRate="0" billRate="0" chargeable="1" clientID="NikuUK" chargeCode="LCOCD1" externalID="L-RESCODE_UK1-PROJ_UK_CNT_GBP-37289-8" importStatus="N" projectID="TESTPROJ" resourceID="admin" transactionDate="2002-02-12" transactionType="L" units="11" taskID="5017601" inputTypeCode="SALES" groupId="123" voucherNumber="ABCVDD" transactionClass="ABCD"/>
<Transaction actualCostRate="0" billRate="0" chargeable="1" clientID="NikuEU" chargeCode="LCOCD1" externalID="L-RESCODE_US1-PROJ_EU_STD2-37291-4" importStatus="N" projectID="TESTPROJ" resourceID="admin" transactionDate="2002-02-04" transactionType="L" units="4" taskID="5017601" inputTypeCode="SALES" groupId="124" voucherNumber="EEE222" transactionClass="DEFG"/>Re: Insert from XML to relational table
http://www.google.ae/search?hl=ar&q=extract+data+from+xml+and+insert+into+Oracle+table+&btnG=%D8%A8%D8%AD%D8%AB+Google&meta= -
XML and XSD file to an internal table
I had read a lot of thread but i don't understand how to deal with xml/xsd in R3.
I need someone that have a definite example for this escenary please.
With OPEN DATASET took from the server XML and XSD file, and put it in two internal tables type string.
What functions or method have to use, and how to use them, to charge the XML file in an internal table?
This is an example of XML and XDS:
XML
AND CONTINUE
Best Regards,I just tried to interpret your question, it was not obvious what you wanted.
I guess what you mean is that you have defined (statically) a deep structure, and you want to decode the XML into it. That is called a transformation (transaction STRANS, statement CALL TRANSFORMATION). You have the choice between 2 transformation languages: XSLT and ST. Of course, it depends what release you are running.
I advise you to play first with the ID transformation, to convert an ABAP deep structured data object into XML, so that you see what XML is generated, this one is called asXML. If you create your own transformation, when you call it, it will first convert automatically the data object to asXML, and the transformation has to do the rest of the job.
You can do the opposite, i.e. converting from XML to a data object, according to the same principle (intermediate asXML).
Well, there are lots of things to say, I recommend you to read articles and documentation on XSLT and ST (search on SDN).
About XSD, it won't help (and I did never see any possibility to use it) to decode the XML, as you must anyway define the target data object statically (and there's no tool to generate the ABAP code of the data object definition from the XSD).
Note that you may also use iXML libraries to parse the XML.
Please tell us more.
BR
Sandra -
XML,CLOB AND MEMORY : CONSUMED BUT NOT RELEASED !!!
Hi,
I'm working with XMLGEN Package and XSLT Processor to produce XML Document on Oracle 8.1.7.3 server, I use 9i XML and Java packages.
I'm facing the following BIG MEMORY problem :
Environment : I must generate an XML parsed with an XSL document of 80Mo (nearly 22 000 rows),
as XMLGEN is on DOM parsing method, I extract my XML by 500 Rows and I loop until 22 000 rows. I use DBMS_JOB with jobs who read and execute export each minute.
The algorithme is :
keeprow=22000
while keeprow>0
Create 3 clob (DBMS_LOB Package) : one for XSL Sheet, one for XML and one for result
GetXML (XMLGEN Package)
Transform in XSL (XSL Processor)
Write to disk (UTL_FILE Package)
Free the 3 Clob ((DBMS_LOB Package))
keeprow =keeprow-500
loop
The problem : The process start at 250Mo ot total memory and END at 1000 Mo of used memory and NEVER RELEASE 1 ko of memory.
So often I get a JavaOutOfMemoryError (I've allocated 1Go Ram to my JAVA process).
Any help will be very very appreciated !
My derived problem is 22 000 rows is not enough I've some export of 200 000 rows to do (And I cannot allocate 10 Go of RAM !!!)
Following My PL/SQL Code.
Regards
Fred
PROCEDURE DO_EXPORT_XML(
P_JOB_ID JOB_PARAMETRE.JOB_ID%TYPE,
P_JOB_ID_ORDRE JOB_PARAMETRE.JOB_ID_ORDRE%TYPE,
P_CLE_UP UPLOADREQ_TEMP.ID%TYPE,
P_LOAD_OR_DELOAD VARCHAR2)
IS
L_FILE_NAME JOB_PARAMETRE.JOB_FILE_NAME_DEST%TYPE;
L_REP_NAME JOB_PARAMETRE.JOB_REP_NAME_DEST%TYPE;
L_FILE_STYLESHEET JOB_PARAMETRE.JOB_STYLESHEET%TYPE;
L_VERSION_PDM JOB_PARAMETRE.JOB_VPDM%TYPE;
P_SELECT varchar2(4000):='';
P_CURSOR varchar2(4000):='';
l_filehandler_out UTL_FILE.FILE_TYPE;
--Variable pour le traitement par lot de 500
L_NBROW_TODO_ATONCE number := 500;
L_NBROW_MIN number := 1;
L_NBROW_MAX number := -1;
L_NBROWKEEPTODO number := -1;
xslString CLOB := null;
res number default -1;
xmlString CLOB := null;
li_ret number := 0;
li_faitle number := 0;
amount integer:= 255;
li_loop integer := 0;
charString varchar2(255);
ls_deload varchar2(255) default '';
ls_SQL varchar2(4000) default '';
ls_temp_file varchar2(255) default '';
text_file_dir varchar2(32) := 'e:\temporarydir';
l_par xmlparser.parser;
l_xml xmldom.domdocument;
l_pro xslprocessor.processor;
l_xsl xslprocessor.stylesheet;
docfragnode xmldom.DOMNode;
docfrag xmldom.DOMDocumentFragment;
l_parsedclob clob := null;
l_amount binary_integer := 32767;
l_ligne varchar2(32767);
l_offset number default 1;
l_pos number default null;
l_pos2 number default null;
l_lobsize number default null;
l_memsize number default 1073741824; --1024 Mo
l_mempipo number default 0;
type rc is ref cursor;
l_cursor rc;
cursor TEMPLATE is select UNSPSC,1 as NB from UPLOADREQ_TEMP where 1=2;
c1rec TEMPLATE%rowtype;
BEGIN
l_mempipo:=setmaxmemorysize(l_memsize);
dbms_lob.createtemporary(l_parsedclob, true, dbms_lob.session);
dbms_lob.createtemporary(xmlstring, true, dbms_lob.session);
--return the good select
GET_SELECT_TO_EXPORT_XML(P_JOB_ID , P_JOB_ID_ORDRE , P_CLE_UP , P_SELECT,P_CURSOR, P_LOAD_OR_DELOAD);
SELECT JOB_FILE_NAME_DEST,JOB_REP_NAME_DEST,JOB_STYLESHEET
INTO L_FILE_NAME,L_REP_NAME,L_FILE_STYLESHEET
FROM JOB_PARAMETRE
WHERE JOB_ID =P_JOB_ID AND JOB_ID_ORDRE=P_JOB_ID_ORDRE;
l_filehandler_out := UTL_FILE.FOPEN(text_file_dir, L_FILE_NAME, 'w',l_amount);
--Return XSL Sheet in a clob : cause of memory consumed but not released
xslString := METACAT.load_a_file( 1,L_FILE_STYLESHEET);
open l_cursor for P_CURSOR;
LOOP
fetch l_cursor into c1rec;
exit when l_cursor%notfound;
L_NBROW_MIN := 1;
L_NBROW_MAX := 0;
L_NBROWKEEPTODO:=c1rec.NB;
LOOP
begin
if(L_NBROWKEEPTODO > L_NBROW_TODO_ATONCE) THEN
begin
L_NBROW_MAX:= L_NBROW_TODO_ATONCE + L_NBROW_MAX;
L_NBROWKEEPTODO:= L_NBROWKEEPTODO - L_NBROW_TODO_ATONCE;
end;
else
begin
L_NBROW_MAX:= L_NBROW_MAX + L_NBROWKEEPTODO;
L_NBROWKEEPTODO:=0;
end;
end if;
--on ouvre le fichier de risultats
ls_SQL:= P_SELECT || ' AND ( ROWNUM BETWEEN ' || L_NBROW_MIN || ' AND ' || L_NBROW_MAX || ' ) and UNSPSC=''' || c1rec.UNSPSC || '''';
ls_temp_file := c1rec.UNSPSC || '_' || L_FILE_NAME;
L_NBROW_MIN:=L_NBROW_TODO_ATONCE + L_NBROW_MIN;
--CAT_AUTOLOAD.JOB_ADD_TRACE (P_JOB_ID,'UPLOAD REQUISITE : Export donnies REQUETE ' || to_char(li_loop), ls_SQL,'',0,0);
xmlgen.resetOptions;
xmlgen.setErrorTag('ERROR_RESULT');
xmlgen.setRowIdAttrName('NAH');
xmlgen.setRowIdColumn('NAH');
xmlgen.setEncodingTag('ISO-8859-1');
xmlgen.useNullAttributeIndicator(false);
if(xmlString is not null) then
dbms_lob.open(xmlString,dbms_lob.lob_readwrite);
l_lobsize:= dbms_lob.Getlength(xmlString);
if(l_lobsize>0) then
dbms_lob.erase(xmlString,l_lobsize,1);
end if;
dbms_lob.close(xmlString);
dbms_lob.freetemporary(xmlString);
dbms_lob.createtemporary(xmlstring, true, dbms_lob.session);
end if;
--Return XML in a clob : cause of memory consumed but not released
xmlString := xmlgen.getXML(ls_SQL,0);
l_par := xmlparser.newparser;
xmlparser.parseclob(l_par, xslString);
l_xsl := xslprocessor.newstylesheet(xmlparser.getdocument(l_par),null);
xmlparser.parseclob(l_par, xmlString);
l_xml := xmlparser.getdocument(l_par);
l_pro := xslprocessor.newprocessor;
xslprocessor.showWarnings(l_pro, true);
xslprocessor.setErrorLog(l_pro, text_file_dir || substr(ls_temp_file,0,length(ls_temp_file)-4) || '_logerreur.XML');
if(l_parsedclob is not null) then
dbms_lob.open(l_parsedclob,dbms_lob.lob_readwrite);
l_lobsize:= dbms_lob.Getlength(l_parsedclob);
if(l_lobsize>0) then
dbms_lob.erase(l_parsedclob,l_lobsize,1);
end if;
dbms_lob.close(l_parsedclob);
dbms_lob.freetemporary(l_parsedclob);
dbms_lob.createtemporary(l_parsedclob, true, dbms_lob.session);
end if;
--Return XML Processed with XSL in a clob : cause of memory consumed but not released
xslprocessor.processxsl(l_pro,l_xsl,l_xml,l_parsedclob);
--release NOTHING
xmlparser.freeparser(l_par);
xslprocessor.freeprocessor(l_pro);
l_ligne:='';
l_offset :=1;
l_pos := null;
l_pos2 := null;
if(li_loop=0) then
begin
--on ouvre le fichier et on sauve l'entete + les donnies dedans.
l_pos:=dbms_lob.instr(l_parsedclob,'</DATA>');
if ( nvl(l_pos,0) > 0 ) then
loop
if(l_pos-1>l_amount + l_offset ) then
l_ligne:=dbms_lob.SUBSTR(l_parsedclob,l_amount,l_offset);
UTL_FILE.PUT(l_filehandler_out,l_ligne);
UTL_FILE.fflush(l_filehandler_out);
l_offset:=l_offset+l_amount;
else
l_ligne:=dbms_lob.SUBSTR(l_parsedclob,l_pos-1 -l_offset ,l_offset);
UTL_FILE.PUT(l_filehandler_out,l_ligne);
UTL_FILE.fflush(l_filehandler_out);
exit;
end if;
end loop;
else
EXIT;
end if;
end;
else
--on met les donnies donc on ne repete pas le debut
begin
l_pos:=dbms_lob.instr(l_parsedclob,'<ITEM');
if ( nvl(l_pos,0) > 0 ) then
l_pos2:=dbms_lob.instr(l_parsedclob,'</DATA>');
if ( nvl(l_pos2,0) > 0 ) then
loop
if(l_pos + l_amount <= l_pos2 -1 ) then
l_ligne:=dbms_lob.SUBSTR(l_parsedclob,l_amount,l_pos);
UTL_FILE.PUT(l_filehandler_out,l_ligne);
UTL_FILE.fflush(l_filehandler_out);
l_pos:=l_pos +l_amount;
else
l_ligne:=dbms_lob.SUBSTR(l_parsedclob,l_pos2 -1 -l_pos,l_pos);
UTL_FILE.PUT(l_filehandler_out,l_ligne);
UTL_FILE.fflush(l_filehandler_out);
exit;
end if;
end loop;
else
exit;
end if;
end if;
end;
end if;
li_loop:=li_loop + 1 ;
--UTL_FILE.FCLOSE(l_filehandler_in);
JAVA_GC();
EXIT WHEN L_NBROWKEEPTODO=0;
Exception
when others then
begin
-- IF(utl_file.is_open(l_filehandler_in)) THEN
-- utl_file.fclose( l_filehandler_in);
-- END IF;
IF(utl_file.is_open(l_filehandler_out)) THEN
utl_file.fclose( l_filehandler_out);
END IF;
RAISE_APPLICATION_ERROR(-20001,'File with errors');
end;
END;
END LOOP;
END LOOP;
CLOSE l_cursor;
if ( xmlString is not null ) then
dbms_lob.open(xmlString,dbms_lob.lob_readwrite);
l_lobsize:= dbms_lob.Getlength(xmlString);
if(l_lobsize>0) then
dbms_lob.erase(xmlString,l_lobsize,1);
end if;
dbms_lob.close(xmlString);
dbms_lob.freeTemporary( xmlString);
end if;
if(l_parsedclob is not null) then
dbms_lob.open(l_parsedclob,dbms_lob.lob_readwrite);
l_lobsize:= dbms_lob.Getlength(l_parsedclob);
if(l_lobsize>0) then
dbms_lob.erase(l_parsedclob,l_lobsize,1);
end if;
dbms_lob.close(l_parsedclob);
dbms_lob.freetemporary(l_parsedclob);
end if;
UTL_FILE.NEW_LINE(l_filehandler_out);
l_ligne:='</DATA></CATALOG>';
UTL_FILE.PUT(l_filehandler_out,l_ligne);
UTL_FILE.FCLOSE(l_filehandler_out);
EXCEPTION
when others then
begin
IF(utl_file.is_open(l_filehandler_out)) THEN
utl_file.fclose( l_filehandler_out);
END IF;
end;
END;
******************************Thank you for the info - I had no idea I was puing myself in danger by cutting it so close. Since your post I have moved my iphoto library to an external drive and now have 165 GB of space on my HD. Following this I have 2 questions.
1. Since my available HD space was reduced by the size of the photo download it seems logical that the download is somewhere on my HD still. Is there a place where these photos might be hiding on my HD even though they are not available on the iphoto library?
2. I was able to recover the .jpg files which are fine. I also recovered the .mov files but they have been compromised. I am hoping I can find the originals still on the HD somewhere. If not, do you have any suggestions for recovery methods or programs? I have not used the SD card since the incident so I should be able to attempt another recovery to salvage the .mov files if there is an alternative method/program available.
Thanks again! -
Defining XSLT from Abap to XML and XML to Abap (Internal Table)
Hi Experts, I need help with this XSLT for call transformation. I have defined an internal table and intend to use it as a source for Call Tranformation. But I have a Problem defining its XSLT and help would be greatly appreciated! I also wonder if this XSLT can be used for XML to internal table? Or do I have to define another XSLT again.... Hope to hear from any of u soon!
CODES->>>
TYPES: BEGIN OF CONTENT,
CONTENT1(20),
CONTENT2(20),
END OF CONTENT.
TYPES: T_CONTENT TYPE TABLE OF CONTENT.
DATA: BEGIN OF I_DATA OCCURS 0,
KEY1(10),
KEY2(10),
CONT TYPE T_CONTENT,
END OF I_DATA.
DATA: WA_TBL TYPE CONTENT.
DATA: LI_TBL TYPE T_CONTENT.
START-OF-SELECTION.
populate data 1
CLEAR I_DATA.
I_DATA-KEY1 = 'AMI'.
I_DATA-KEY2 = 'LEE'.
CLEAR WA_TBL.
REFRESH LI_TBL.
WA_TBL-CONTENT1 = 'PENHAS ROAD'.
WA_TBL-CONTENT2 = 'SG'.
APPEND WA_TBL TO LI_TBL.
WA_TBL-CONTENT1 = 'GILLMAN ROAD'.
WA_TBL-CONTENT2 = 'SG'.
APPEND WA_TBL TO LI_TBL.
I_DATA-CONT = LI_TBL.
APPEND I_DATA.
populate data 1
CLEAR I_DATA.
I_DATA-KEY1 = 'KAI'.
I_DATA-KEY2 = 'LEE'.
CLEAR WA_TBL.
REFRESH LI_TBL.
WA_TBL-CONTENT1 = 'SUNSET WAY'.
WA_TBL-CONTENT2 = 'SG'.
APPEND WA_TBL TO LI_TBL.
WA_TBL-CONTENT1 = 'BEDOK NORTH'.
WA_TBL-CONTENT2 = 'SG'.
APPEND WA_TBL TO LI_TBL.
I_DATA-CONT = LI_TBL.
APPEND I_DATA.
call transformation (xslt)
source i_data = i_data
result xml xmlstr.here is the code sample using ixml library .
just create a report program and copy paste the following code.
if time permits, later on i will post the xslt program which you can use it call transformation.
REPORT y_test_xml.
DATA: l_ixml TYPE REF TO if_ixml,
l_ixml_sf TYPE REF TO if_ixml_stream_factory,
l_istream TYPE REF TO if_ixml_istream,
l_ostream TYPE REF TO if_ixml_ostream,
l_booklist TYPE REF TO if_ixml_element,
l_document TYPE REF TO if_ixml_document,
l_parser TYPE REF TO if_ixml_parser,
l_root_element TYPE REF TO if_ixml_element,
l_book_record TYPE REF TO if_ixml_element,
l_date TYPE REF TO if_ixml_element ,
l_time TYPE REF TO if_ixml_element ,
l_book_group TYPE REF TO if_ixml_element,
l_book_cat TYPE REF TO if_ixml_element ,
others TYPE REF TO if_ixml_element ,
link TYPE REF TO if_ixml_element ,
description TYPE REF TO if_ixml_element ,
xml TYPE xstring ,
size TYPE i ,
l_xml TYPE REF TO cl_xml_document .
DATA: xml_out TYPE string ,
temp_string TYPE string .
TYPES: BEGIN OF add_category,
category_id(10),
category_desc(40),
END OF add_category,
add_t_category TYPE add_category OCCURS 0 .
TYPES: BEGIN OF add_book_grp,
book_category TYPE add_t_category,
END OF add_book_grp,
add_t_book_grp TYPE add_book_grp OCCURS 0.
TYPES: BEGIN OF add_book,
book_num(10) TYPE c,
short_desc(40) TYPE c,
book_group TYPE add_t_book_grp,
END OF add_book,
add_t_book TYPE add_book OCCURS 0.
TYPES: BEGIN OF type_data,
date TYPE sy-datum,
time TYPE sy-uzeit,
book_record TYPE add_t_book,
END OF type_data.
DATA: i_data TYPE type_data OCCURS 0 WITH HEADER LINE.
DATA: itab LIKE soli OCCURS 0 WITH HEADER LINE.
DATA: cat_wa TYPE add_category ,
bk_gp_wa TYPE add_book_grp ,
bk_rec_wa TYPE add_book ,
bk_wa LIKE LINE OF i_data .
DATA: cat_tab TYPE STANDARD TABLE OF add_category ,
bk_gp_tab TYPE STANDARD TABLE OF add_book_grp ,
bk_rec_tab TYPE STANDARD TABLE OF add_book .
MOVE: '03' TO cat_wa-category_id ,
' BK GP 3' TO cat_wa-category_desc .
APPEND cat_wa TO cat_tab .
MOVE: '02' TO cat_wa-category_id ,
' BK GP 2' TO cat_wa-category_desc .
APPEND cat_wa TO cat_tab .
bk_gp_wa-book_category = cat_tab.
APPEND bk_gp_wa TO bk_gp_tab .
MOVE: '0012345678' TO bk_rec_wa-book_num ,
'OMS book' TO bk_rec_wa-short_desc .
bk_rec_wa-book_group = bk_gp_tab .
APPEND bk_rec_wa TO bk_rec_tab .
CLEAR:bk_gp_tab, cat_tab .
REFRESH :bk_gp_tab, cat_tab .
MOVE: '01' TO cat_wa-category_id ,
' BK GP 1' TO cat_wa-category_desc .
APPEND cat_wa TO cat_tab .
MOVE: '09' TO cat_wa-category_id ,
' BK GP 9' TO cat_wa-category_desc .
APPEND cat_wa TO cat_tab .
bk_gp_wa-book_category = cat_tab.
APPEND bk_gp_wa TO bk_gp_tab .
MOVE: '00123456789' TO bk_rec_wa-book_num ,
'SAP book' TO bk_rec_wa-short_desc .
bk_rec_wa-book_group = bk_gp_tab .
APPEND bk_rec_wa TO bk_rec_tab .
MOVE: sy-datum TO bk_wa-date ,
sy-uzeit TO bk_wa-time .
bk_wa-book_record = bk_rec_tab .
APPEND bk_wa TO i_data .
CLEAR: cat_wa , bk_gp_wa ,bk_rec_wa , bk_wa .
l_ixml = cl_ixml=>create( ).
l_ixml_sf = l_ixml->create_stream_factory( ).
l_document = l_ixml->create_document( ).
l_root_element = l_document->create_element( name = 'asx:abap' ).
l_root_element->set_attribute( name = 'xmlns:asx' value = 'http://www.sap.com/abapxml' ) .
l_root_element->set_attribute( name = 'version' value = '1.0' ).
l_document->append_child( new_child = l_root_element ).
others = l_document->create_simple_element( parent = l_root_element name = 'asx:values' ).
l_booklist = l_document->create_simple_element( parent = others name = 'BOOKLIST' ).
LOOP AT i_data INTO bk_wa .
CLEAR temp_string .
MOVE: bk_wa-date TO temp_string .
l_date = l_document->create_simple_element( parent = l_booklist name = 'DATE' value = temp_string ).
CLEAR temp_string .
MOVE: bk_wa-time TO temp_string .
l_time = l_document->create_simple_element( parent = l_booklist name = 'TIME' value = temp_string ).
LOOP AT bk_wa-book_record INTO bk_rec_wa .
l_book_record = l_document->create_simple_element( parent = l_booklist name = 'BOOK_RECORD' ) .
CLEAR temp_string .
MOVE: bk_rec_wa-book_num TO temp_string .
l_date = l_document->create_simple_element( parent = l_book_record name = 'BOOK_NUM' value = temp_string ).
CLEAR temp_string .
MOVE: bk_rec_wa-short_desc TO temp_string .
l_time = l_document->create_simple_element( parent = l_book_record name = 'SHORT_DESC' value = temp_string ).
l_book_group = l_document->create_simple_element( parent = l_book_record name = 'BOOK_GROUP' ).
LOOP AT bk_rec_wa-book_group INTO bk_gp_wa .
LOOP AT bk_gp_wa-book_category INTO cat_wa .
l_book_cat = l_document->create_simple_element( parent = l_book_group name = 'BOOK_CATEGORY' ).
CLEAR temp_string .
MOVE: cat_wa-category_id TO temp_string .
l_date = l_document->create_simple_element( parent = l_book_cat name = 'CATEGORY_ID' value = temp_string ).
CLEAR temp_string .
MOVE: cat_wa-category_desc TO temp_string .
l_time = l_document->create_simple_element( parent = l_book_cat name = 'CATEGORY_DESC' value = temp_string ).
ENDLOOP .
ENDLOOP .
ENDLOOP .
ENDLOOP .
l_ostream = l_ixml_sf->create_ostream_xstring( xml ).
l_document->render( ostream = l_ostream ).
CREATE OBJECT l_xml.
CALL METHOD l_xml->parse_xstring
EXPORTING
stream = xml.
l_xml->render_2_string(
EXPORTING
pretty_print = 'X'
IMPORTING
* RETCODE = RETCODE
stream = xml_out
size = size
CALL METHOD l_xml->display.
Hope this is helpful.
do let us know how it goes.
Regards
Raja -
How to fetch data from XML and store it in internal table
Hi All,
Can anyone help me out, in fetching data from xml and store it in an internal table. Is there any standard function module is there?
Regards,
Karthickto do this you can either develop a XSLT program and use it with CALL TRNSFORMATION key word to tranform the XML into itab .
(search the ABAP General forum, i have posted few samples)
or simply use the following FM which converts your XML into a itab of name value pair (name would holw the element name and value would hold the value of the element) which you can then loop and read it to your itb.
data: xmldata type xstring .
data: result_xml type standard table of smum_xmltb .
data: return type standard table of bapiret2 .
CALL FUNCTION 'SMUM_XML_PARSE'
EXPORTING
xml_input = xmldata
TABLES
xml_table = result_xml
return = return .
Regards
Raja -
How to Convert internal table data into xml and xml data into internal tab
Hi Guys,
I have a requirement that i have to convert the internal table data into xml format and viceversa . for my requirement i came to know that i have to use Transformations concept. i done the converting the data from internal table into xml data by using standard Tranformations. My Question is
1) Can i use same Transformation to convert the xml data into abap internal table. if it is possible then how ???
2) Is it possible using the standard Transformation or I have to go for XSLT approach
Please help me out from this guys,
Thanks and Regards
KotiHi Koti,
This is possible. There is a link. With the help of this link you can convert ABAP data to XML and vice versa.
Link: http://www.heidoc.net/joomla/index.php?option=com_content&view=article&id=15:sapxslt&catid=22:sap-xslt&Itemid=31 -
Newbie - XML File - How to load data and populate tables
Hi,
I'm newbie to XML data handling.
I have a file that is provided in XML format with data from an external system.
I need to load data from that file and populate some field in one or more tables.
I have two options:
1. Load the XML file directly from OS and populate the tables directly (I'm not sure if this is possible or not)
2. Load the entire XML file from OS into a CLOB or a BLOB(?) and the select the data form the CLOB and populate my tables.
I need some guidance about what is possible and how to do it.
My preferred approach if possible is to load the data directly from OS and populate the target tables without loading into the database previously.
Thanks for the help.
Tech Info:
OS : Unix / Windows
DB Version: 11.2 or 11.1
JFforum has many examples
use search
as example see
Re: Load xml data in Oracle table
Re: Load an XML file into table(s)
Re: load a file -
Help needed XML to Internal table and vice versa
Hello frnds, I need to convert Internal table to XML and Vice versa.
Now I am able to most of the part except for this...
the xml which I have to generate looks something like this...
- <trade_dt>
- <![CDATA[ 20111108000000:20111108235959
]]>
</trade_dt>
its a range I think
And then the reponse which I get back the XML is like
- <lockinfo>
- <![CDATA[
TRD_HEADER 1045 1 2
ACT_CASHFLOW 1042 1
TRD_TERM 1045 2
]]>
</lockinfo>
Is there any provision in class cl_ixml or class if_ixml_element to handle this part.....
Edited by: Amit Sawant on Dec 28, 2011 3:51 PMHello Amit,
I would suggest you, to use the XSL-Transformations, which can be inbound used in ABAP.
For example:
DATA:
l_xml TYPE string,
lt_flights TYPE TABLE OF SFLIGHT.
SELECT * FROM SFLIGHT INTO TABLE LT_FLIGHT.
CALL TRANSFORMATION id
SOURCE DATA = lt_flights
RESULT XML l_xml.
Now, you have a XML-String which is in the ABAP-XML Notation, which means, that ABAP can move this XML-Data back into an internal table/structure.
For the backward, you have to use the following statement:
CALL TRANSFORMATION id
SOURCE XML l_xml
RESULT DATA = lt_flights.
As you will see, it is very easy. The Transformation "id" is just one example and build in. When you have to transform the data, or do not want to have the ASX-Notation in it, you should at least define your own transformations with the transaction XSLT_TOOL and use it similar to the transformation "id".
Kind Regards,
Hendrik -
Hi everyone,
I'm just starting to explore the possibilities of XML in InDesign and in need of some general information:
The projects that I'm working with that I think would benefit from the XML workflow are files that include a number of tables (e.g., product names, descriptions, prices, etc. with header rows and some merged cells).
The content of the tables are the same for a brochure-style layout and a poster-style layout but the brochure tables need to be tall and narrow and the poster tables short and wide (basically flipping the axes). So far I've handled this through a complicated dance of exporting the tables as text and using Excel to flip the axes and then import the tables back into InDesign (in order for this to work, I have to un-merge all merged cells and it still isn't perfect but a reasonable starting point).
The editors make changes to the content in InDesign using InCopy (adding or removing rows or columns to add new products and/or prices, etc.)
The poster and brochure versions of the file don't need to be live at the same time--they're used at different times of the year so it's a matter of loading the final brochure content into the poster then making any changes to the poster and 6 months later importing the final poster content into the brochure. And the cycle continues.
Would XML handle well? The little I've read so far about XML and tables indicates that each cell would need to be tagged. This could easily result in mis-tagging a cell which would screw up the content import, right? I'm talking about hundreds (thousands?) of cells.
And since the structure of the table would be changing due to adding/removing rows/columns, it seems I would need to tag each cell of the tables every time I wanted to import content.
Am I understanding all this correctly?
Thanks for your input.Hi
You are right each cell nee to be tagged in XML tables, if you are working with more than hundreds/thousands of cells, be careful in content tagging. adding/removing columns/rows would really affect the structure of the XML and if it need to extract/export the content the structure of XML will not be correct. It is better to avoid XML tables in case of adding/removing columns/rows. -
XML Schema Based Table and ORA-22814
When I want to insert clob into XML Schema Based Table, ORA-22814 was occured.
Why?the instance document ( I can't insert ):
<nesne xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.yore.com.tr/tkword.xsd" nesne_id="Resim3d1df48649498"><resim><altyazi></altyazi><httpBaslik>image/jpeg</httpBaslik><icerik><![CDATA[ffd8ffe000104a46494600010201012c012c0000ffed089450686f746f73
686f7020332e30003842494d03ed000000000010012c200000010002012c
2000000100023842494d03f300000000000800000000000000003842494d
040a00000000000100003842494d271000000000000a0001000000000000
00023842494d03f5000000000048002f66660001006c6666000600000000
0001002f6666000100a1999a0006000000000001003200000001005a0000
0006000000000001003500000001002d000000060000000000013842494d
03f80000000000700000ffffffffffffffffffffffffffffffffffffffff
ffff03e800000000ffffffffffffffffffffffffffffffffffffffffffff
03e800000000ffffffffffffffffffffffffffffffffffffffffffff03e8
00000000ffffffffffffffffffffffffffffffffffffffffffff03e80000
3842494d0408000000000010000000010000024000000240000000003842
494d040900000000072400000001000000800000001a0000018000002700
0000070800180001ffd8ffe000104a46494600010201004800480000fffe
002746696c65207772697474656e2062792041646f62652050686f746f73
686f70a820342e3000ffee000e41646f626500648000000001ffdb008400
0c08080809080c09090c110b0a0b11150f0c0c0f1518131315131318110c
0c0c0c0c0c110c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
0c0c0c0c010d0b0b0d0e0d100e0e10140e0e0e14140e0e0e0e14110c0c0c
0c0c11110c0c0c0c0c0c110c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
0c0c0c0c0c0c0c0c0cffc0001108001a008003012200021101031101ffdd
00040008ffc4013f00000105010101010101000000000000000300010204
05060708090a0b0100010501010101010100000000000000010002030405
060708090a0b1000010401030204020507060805030c3301000211030421
1231054151611322718132061491a1b14223241552c16233347282d14307
259253f0e1f163733516a2b283264493546445c2a3743617d255e265f2b3
84c3d375e3f3462794a485b495c4d4e4f4a5b5c5d5e5f55666768696a6b6
c6d6e6f637475767778797a7b7c7d7e7f711000202010204040304050607
070605350100021103213112044151617122130532819114a1b14223c152
d1f0332462e1728292435315637334f1250616a2b283072635c2d2449354
a317644555367465e2f2b384c3d375e3f34694a485b495c4d4e4f4a5b5c5
d5e5f55666768696a6b6c6d6e6f62737475767778797a7b7c7ffda000c03
010002110311003f00f4bcfcfc6e9f8afcac92456d21a1ac697bdef7115d
54d3533df6dd6d8e6d7556cfcf5c767ff8cdc0c5cb7e3db938b8af63b6ba
9db6e5bdbc1fd62ec4f4f12bb5b3b2da716ecff4ecff000eb47ebb3ee6b6
bf49ce0f662e4be90d241163dd8b82ebeb70fa1753899b94dadff99ebaf3
2c4fa8b8b93d57129b727d0c4b2d6b32a35731903e8bfdcd6bedb3f41eff
00e6b7fa9624a7d87a075cafac615796d0cd97177a16d4e73ebb1ac3b5ce
acdb5e3dd5bdaef6be8be8aecfa7e9fad57e956aae07eadddd54f54a5bd4
7159d3ada3a55028c3acbb6b40ca7d7fd1dfe8bb1acb36b68f4fd4bbd4af
fc35dfcd26fac56f56abfc65e1bba3d14e4e67eca20577bcd6cdbeadfb9d
b9bf9c929ef93af34fae191f5b6f6746afade16262e37ed6c5d8fc7b4bdc
6cfd286b1cd77e66cf53dca87d69fdb3f5d7ad6559d271b232ba6748dd8d
837635b556dfb682c7bf25efb8fe92afcdfd03ff009bfb3dbea57eaa4a7d
6925e4dd37eb3bfa6754c6fad1900d5566b874cfad38db4875399482da73
4d2ddbb7d5637d4db5d3fe0f329fe91620756b3a8756fab3d7bebb640754
73cd785d358241af09b731968f6b9dfd25dfa2bbff00423fc164a4a7d821
285e33fb1fead7fdc6fabdff00b97caffc9adce8d97d27a4fd6de9b6e45f
8785863a09654faef36636efb5daef4e8cbc93badfcefa6e494fa4a785cf
e77d67fabd9b83918783d730e9ccc9a9f4e35adbd92cb5ed35d363763b76
e658efcd5e674745e8f5d4caefaba065dcd116653bab5cd363bf3ae731b7
57b3d4fea24a7db132f221f581b91f554fd54fab184da3a9e7e55f8cfc7c
7b9d7b0d2c6b5f959746464bff0098cbfe66bdeff4fd3fb4abff0055b33a
97d5a7e7fd5acea323028cca2ecae88722c63ded7b58ef5a817e3fe877bb
6fadedf4bd37ff0083fd69253e9c92f29faacdeb3f55feaee17d67e9bea6
7f46ca617f59e9c4ee7d458f7d4eea385f47e8b2bfd619ff006f7e87f4b8
3d07f8bacbc5ceea3f5973b0dfeae364e70b2ab76b9bb9ae0e7fd1b1ac7f
e724a7ffd0f44eb5d29bd4f14561c2bbab25d53deddecf735d4db4df56e6
7ad8d914596537d7bffe12af4afae9b6be36dfab7d4a8758d0cc966e1b5c
c35b72d8e61d1edaf2a9bb1df90dfcca3edf878d77a7fce2f414925385d1
3a6e6fe86dcfadd5fd95be9d565ce63f2ed6825c1b96fa7d56578f5bff00
494e3b72f27d4fd1db77a5e9fa2b60e262bb25b98ea6b394c61adb905a3d
40c2773ab6db1bfd3ddf988a924a4593878798c6b32e8af2195bc58c6dac
6bc35edfa16343c3b6d8d9fa696261e1e15231f0a8af1a86924554b1b5b0
13ab8ecac35bee454925352ce8fd22d6e4b6cc1c778cd2d3961d530fac58
7756ec8f6fe9bd377d0f53e8231c4c538bf6334d671767a5f672d1e9fa60
6df4bd28f4fd3dbedd88a924a737fe6cfd5bff00ca9c2ffd87abff0049a3
59d17a35b4d58f6e0633e8c7045153a9616560fd214b0b76d7bbf90ae249
29a0cfabfd02b7b6cafa66231ec32c7b68ac107f79ae0c51ff009b5f5706
83a5617fec3d5ff905a2924a6b63f4be998b6b6ec6c3a28b58cf49b65753
18e15ceef45af6343bd2ddfe0d4b2703072dd5bb2f1aac87504ba975ac6b
cb09e5d5ef0ed8efeaa3a49291e3e3e3e2d2cc7c5a99451588aeaada18c6
8f063190d6a6c5c3c3c3acd3874578d517179ae96358ddcefa4fdb586b77
39152494ff00ffd93842494d04060000000000070000000000010100fffe
002746696c65207772697474656e2062792041646f62652050686f746f73
686f70a820342e3000ffee000e41646f626500648000000001ffdb008400
100b0b0b0c0b100c0c10170f0d0f171b141010141b1f17171717171f110c
0c0c0c0c0c110c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
0c0c0c0c01110f0f11131115121215140e0e0e14140e0e0e0e14110c0c0c
0c0c11110c0c0c0c0c0c110c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
0c0c0c0c0c0c0c0c0cffc0001108008f02b103012200021101031101ffdd
0004002cffc4013f00000105010101010101000000000000000300010204
05060708090a0b0100010501010101010100000000000000010002030405
060708090a0b1000010401030204020507060805030c3301000211030421
1231054151611322718132061491a1b14223241552c16233347282d14307
259253f0e1f163733516a2b283264493546445c2a3743617d255e265f2b3
84c3d375e3f3462794a485b495c4d4e4f4a5b5c5d5e5f55666768696a6b6
c6d6e6f637475767778797a7b7c7d7e7f711000202010204040304050607
070605350100021103213112044151617122130532819114a1b14223c152
d1f0332462e1728292435315637334f1250616a2b283072635c2d2449354
a317644555367465e2f2b384c3d375e3f34694a485b495c4d4e4f4a5b5c5
d5e5f55666768696a6b6c6d6e6f62737475767778797a7b7c7ffda000c03
010002110311003f00efd2492494a4924925292492494a49249252924924
94a4924925292492494a4924925292492494a4924925292492494a492492
5292492494a4924925292492494a4924925292492494a492492529249249
4a4924925292492494a4924925292492494a4924925292492494a4924925
292492494a4924925292492494a4924925292492494a4924925292492494
a4924925292492494a4924925292492494a4924925292492494a49249252
92492494a4924925292492494a49249253ffd0efd2492494a49249252925
1739ac6973886b5a24b8e8001e2b8ffac5f5f598363f0fa7d7ea64088b5d
05bee1b9aead8d3fcaf67abffb0e929ea733a861e0b3764da19a176d00b9
e5a2039eda6a0fb5cc6eefdc5cd750ff0018bd2b1cedc561c83b49266358
fd1b5bb1b631dfcbfd257e92c6c5faa7f583eb1dcecfeb571c3a6e77a82b
8f79d1ac6edc6ff03fa16fa7ea647e9ff47fcdaea303ea6fd5be99592ec7
65ee025d76545874976edb60fb3d7b7fe0ea494f327fc6575175d18f895d
cc3a359b1cd7c9fa3ee6645fff009ed4c7f8c2ebac6fa97f4a6fa7fbc058
c1fbff004dfea37f9b73174d6fd6afaab8503edb48998f401b07feca32d4
31f5ebeaa9207dbb9f1aad1ffa212538189fe337de5b9b8a0493b4d72d0d
1f9beaee7def77bbf72a5d1749fadfd1faa3bd3aec15dba7b5da4e92edbb
b659ecff0049e97a48edccfab3d688abd4c4cd7bb5153b63dfedddeef46d
fd2fb3deb23aa7f8bae8f940bf05cec1bb91b7df5cccff0032f3bdbff5ab
5253d6275e714657d70faad955636556ecec5b1de9d30e2f638bbe8b2ab7
fc1bff00e0ef67fc5af461c7824a5d2492494a4924925292492494a49249
25292492494a4924925292492494a4924925292492494a49249252924924
94a4924925292492494a4924925292492494a4924925292492494a492492
5292492494a4924925292492494a4924925292492494a492492529249249
4a4924925292492494a4924925292492494a4924925292492494a4924925
292492494a4924925292492494a4924925292492494fffd1efd2492494a4
925ccfd76fac07a4f4f34d0edb95920b6b20896f1b9db4b5ff00ebff0018
929c6fae1f58b233f35bd0ba3fe99ce3b1fb60eeb25cc757b2cafdbe86cf
52bbfd6ff87ff417ad7fab3f53f0fa2d6dcfcd22dea3b773ec7905949d5c
ff00427f3b6ff3b7bffeb7e9207d45fabc31317f6ce7b77e7e5fe92b7bce
e2ca9e377a9afd1bf277bdf77bff009af4ff00e1962fd73fad96e7596f4e
e9d69660d5babc9b5a47e9ddfe8abfcff458e66cfd1ff3ff00f11fce253a
5f58bfc62538cf762f466b722d6921f94ed6a1ff0085dadfe91ff19fccff
00e185c167f55ea3d4acf573f21f7ba64071f6b7fe2aa6fe8aaffadb1544
925292492494a5b5d23eb775ce92e029bcdd40d3ecf7cd8c8036b433ddea
53b7fe06cad62ab5d33a764f54ceab07140375c6013a35a07b9f63ddfb8c
624a7d7beae7d62c6fac188ebe9adf4d9510dbab76a0388ddfa2bbe85acf
fc13fd2555a1752aeee999b7fd62b73af760d34edb3a731a1cc3f99beadc
edacf7fe97e87abfce7eb5f66fd0abfd27a5e2749c1af0b11bb58c1ee77e
73df10fbadfdeb1ea9f53fac7d2f13371fa5bc8c8cbcab6ba4d0d83b058e
6b3d4ca9fe6fdafdfe97f3b6ff00e08929bfd37a863f53c1a73b1a7d1bdb
b9a1c36b86bb1ec737f90f6ecffcf6ad2c56d9d6f1bac5cfca7e353f57eb
6015b890c209fceddfbfea7b2cf53f43fe896ca4a5d2492494a49733d67e
bce0747cf7e05f8f6d8f6004babdb1ee13f9ef6aab47f8c8e979191563d5
8b7efb9edada5db0005e7d36976db1e929ec12492494a4924925292517bb
6b1cee768263e0b8e7ff008cce94c7b98ec4c8969234d9c831fe91253d9a
4b9de81f5cb07aee6bb0f1e8b6a7b6b369759b621a6baf6fb1efff004aba
2494a49250baeaa8a9d75cf6d75306e7bdc61a00fce739c9299a4b86cdff
0019d8b5dae660e1baf60d1b6d8ff4e7c7f46d65bec4d85fe33f16cb5acc
ec2750c275b2b7fa91fbbfa2732a494f74921d1755914b2fa1e2caac01cc
7b4c8734ead73562fd60fad78dd02daabcac7b6c6dc0963ebdb1eddbbdbf
a4733f7d253bc92e2c7f8cee91df13207c367fe955d6606763f51c3a7371
9dba9bda1cdf113f498f8ff095bbd9624a6c249249294924abe766e3f4fc
4b73329db29a5bb9e7fefadfe5bddec624a6c24b8b3fe33fa476c4c8ff00
a1ff00a556a740fadd8dd7f22ca31716eadb53773edb36ed13f419fa373f
def494f4092c8eb1f5a7a2f4696e5dfbaf8918f50df61feb37e855ff005f
b2a580ff00f19fd3038ecc3bdcdec49603c7ee873d253db24b873fe34307
58c1b4f84b9bfcaffcc3fd6bfd22ff00c74303fee0dbf1dcd494f7092e18
7f8d0c3ddae0d9b7c77b6674f2febffaff00368ff8d1c38f6e0593e05edf
3fe4a4a7b94970c3fc686169bb06de7587b789ff00c8ab5d23fc60e3f54e
a3460370df53af3b43cbc100c6efddfeba4a7af49657d61ebb5f42c26e65
949b9a5e19b5a434ea0fef2e77ff001d0e9fff0070aeff0039a929edd255
3a567b7a974ea33dac35b7219bc309923fb415b494a4924925292492494a
492547aa75ae9bd22917750bc54d7186b60b9ce3fc8aabdcf494de497179
1fe33ba531c5b8f8b75a0180e76d6023f7dbee7bd03ff1d0c5ff00b8367f
9c1253dda4b84ffc7431a7fa0be3fac123fe3431bb60bffce0929eed25c3
33fc67e16bea61da3c36969ffaa73547ff001d0c6ffb82ff00f3824a7bb4
9739f56feb851d7b26cc66d0fa5f5b77c98208feb05d1a4a52492a5d5bab
61747c376666bf6d60801a35739c78aea67e7392537525e7d6ff008d27ef
228e9c3d39f697dbee23f94d655ecff3d69745ff00189d3f3f2198d9b49c
2b2c30db0bc3aae3fc25aef49d5eff00ea24a7af49327494a49255b3fa8e
1f4dc676566da2aa59dcf73fb8c6fe7d9fc8494d94970791fe34686dc5b8
d80eb29074b1f606388ff8a6d56ffe7d5b9d0beb9f49eb4f18ed2ec6cb3c
536c7ba3fd0d8df659ff009f7fe0d253d024993a4a5249285af35d4f78d4
b5a5c3e4252533497083fc68e347bb01f3e560ff00c82dbfab3f5aebfac3
66432bc7340c70d32e707176e2edbf45addbf41253d0249249294924924a
7fffd2efd2492494c5ef0c639e786824fcb55e658d5bbeb37d736d77eebb
1719ce7db311b6b25fb1db7f47e93f23d2c5f67f80ff00b7177bf58333ec
5d1b2f20004b6b20031acfb5ff004fdbfcdef5ccff008b1c63f63cecf712
e7dd68aa4ccfe8dbeb39d3fcbfb524a753eba753b31702be99886333aa3b
d0a88e18cf63722ce3f72cf4bfeb9ea7f835e67d44d7ea1c7a8fead87fa2
a888fd259ff6a2ff00faf58d7dbff11f67a1759f58f3864756eadd41a61b
d2a86e1531acdd79b2ab2cfcdd9e9fa9915ffd6d738718517b6a7b41afa7
502fbc100875f6065adaadd7dffad5d8d8567fc0d0929cc7d0e61dbcbdad
dcf1d9a0c7b5dbbf3fddff00a2d096a3f15e2aae925deadec3979af1aeda
7f9ca777d1fccfd3ff00c25b763acf34bcb5af0d2058e8a9b049776f67ef
6dfa09291a4924929404e8395eb1f52beacb7a361fdab25a3f6864b417f8
d4c30ffb36bf9dfe9ffe13fe2d72df533a133d3b7eb1f506176160b6cb2a
a809363ea6ef7d8df536b1ccabfc17fdd9ff008a573a2fd6cea5d77eb760
b6c271f0c7abb716b71da7f457bf7643bdbf68b7fb1ff175d6929f445e2f
d25ce7fd6ac47bc973dd9cc2e71e4936b4b9ce5ed0bc5ba3c1fad387b440
fb75700f61eab5253eb7d67a5e2756e9f661e6178a0c3dc6b30ef61dfedf
6d9ff5083f57ba974eea3d39aee98d7b31318fd9ab6bc418a9ac0cdbb9f6
3f67a4eaff009cfd2ffa45a8b2ba7e6759bbaa6763e661371fa7d240c4bc
3a5d66bb773bf32cf59bfa6ff03f65fe62cf5bf9c494eaa4924929f23faf
dff8a4bffaacfc8b27a309eb1823feec53ff0056c5adf5fbff0014b91fd5
67fd4ac7e90f657d570ac790d63322a738930000f61dce724a7dd12544f5
be8e3fed6d1e1fce37bff6937edde8dff73a8f1fe71bf1f1494df4950fdb
9d1bfee751ff006e37fbd2fdb9d1a63edd44ff00c637ff0024929b9609ad
c3c41fc8bc27334cbbc7fc23ff00ea9cbda1fd73a3fa6edb9b4125a63f48
dd74feb2f16ca70764dce0410e7b88238d49494f53fe2d3fe5fb7ff0abff
00eaf1d7a8af2eff00169ff2fddff855ff00f578ebd452529705fe31faf6
c637a2504ee786db9241d36cfe8a8ff39beb7fdb7fe91767d4b3e8e9b837
66e418ae969747771fccadbfcbb1cbc4b3f3afea399766e49dd75cedce3d
bf75adfec33d8929ae92d1e83d22ceb3d529c1612d6be5d6bc09dac6fd37
7fdf107aaf4ebba667dd85708754e21a7f79b3ec7a4a7b5ff16fd71b1674
5bddef936e2c9e447e9e86ff00576fadff006eae93eb6f461d5fa3db531b
39158f5283fca6fe6ff6ff009aff00ae2f21c3cbbf072aacbc776dba9707
b0fc3f35dfc97af6de95d468ea9814e7506596b4123bb5dfe12b747ee392
53e1af6398e2c782d7b490e6910411f49ae6aedbfc5d75f34643ba3e4bff
00437fbb164986d9f9f4b3fe3ff9cffadffc22cdfaf5d14f4deaeec8ac7e
af984d8df27ff87ff3f77abff6e7fa35ce556d94d8cb6a716595b8398e1a
10e07735c1253efa92cafab9d66beb5d2a9cb047ad1b32183f36c6ff0039
edfe5ff3b5ff00c1ad5494a5e73fe31baf9b6f1d131cfe8e92d7e491225f
1baba3f96c631feaff00c67fc5aecfeb0f59a7a2f4cb732c8366aca19fbd
690ef49bff0047debc5adb6cbad7dd6b8becb0973dce32493f49ce494c17
a6615167d51fa9f765c4e6581af7070fa36dbb6a6b7e97d0abd9f43fd1fa
ab94fa95d19bd57acb3d66eec6c61ea5808d1ceff0357fe8dffacaedbfc6
100dfab2f68d00b6a007cfcd253e55658fb6c759612e7bc9739c79249dce
728a4bd33ea666741abeaed0cccb716bb83acde2e35b5d3b9c5ae77a9eef
e6d253e6692f673d47eaa7fa7c2fbeb4bf697d553ff6a30bfcea9253e309
2f67fda5f553fee4610fed5490ea3f554f17e14f6d6b494f8c2dbfa9627e
b3e07f5dc7ee658bd33f697d55063ed185e3f4aa44c6cefabb6e43062dd8
8ec871860acd7ea131f99b3dff00452538bfe324ff009059e7737f239797
2f52ff00191ff2037fe3d9f91ebcb5253ecff54bff00137d3ffe247e572d
858ff54fff00137d3bfe247e52b6125292492494a492492520ceca661e1d
d9767d0a18e7bbe0d1b9789754ea795d5736ccdca7175961d0766347d0aa
bfe4317aff00d689ff009bbd463fee3bff0022f15494a497a07f8bfeabd2
30ba45f567e453458ec8739adb5cd0e2d35d0dfcefccf62ea3fe717d5aff
00b9f8bfe7b5253e2e92f69ff9c7f56bfee7e2ff009ed4bfe71fd5affb9f
8dfe7b5253e2c92f69ff009c7f56bfee7e2ff9ed56713a8f49cd91879145
e4448adcd7113f47dad494f9ff00f8b364f56c87feed31f79ffcc57a6a88
6b4190003e202924a59793fd7aebaeea7d54e35366ec2c486d61a65af7c6
eb6ff6fe77bbd0ff00adaee3eba75d3d1fa4bbd17465e49f4e9e0ed9fe76
eda7f719ff0082fa6bc85252925b9f573ead5dd7464b9ae2c6d35b8b08ef
644b18efe42c5b2b7d563abb06d7b096b9a7b1076b9a929f58fa8dd74f56
e95e8dc67270b6d4f24c97363f437bbfe3363d74abc63eab75a7f46eaf4d
e5c4635845792dec587dbea39bff0001bbd55ecad735ed0e6996b8483e45
25325e5ffe317aa5d91d55bd3f514e30ddb7c5eefcefecb3ff003e5abd41
790fd7affc52e4fc1bf91253cf270482083046a0856fa3e35797d53171ad
1babbac0c70d4687fa9ee577eb1fd5bcbe8395b1f3662bcfe86f8e7fe0ec
fdcb7ff3e7fdb95d694f61f537eba0cc0ce9bd56c03284fa590e200b47e6
54ff00a3fac7fe7dff008d5daaf010482083047057a3fd4cfae9f6ad9d2f
aabff58d45392e3a3e3fc1def7bbf9ff00f47fe97fe37f9c4a7b842c9fe8
d6ff0051df911143204d168f163bf224a7c11779fe2b4fe9ba88fe4d5f96
d5c1aef3fc577f3dd43fab57e5b5253e86924924a524924929ffd3efd249
2494f3df5ef68fab19649870f4f6eb124beb6bbfe86f50fa8148abeac633
844dcfb5e63c77be9f77fdb489f5eab0ff00ab197224b76387910f67fdf5
0bfc5fddeafd59a1b20fa2fb1840edef75d0effb75253c93ddf68c5b446e
1d47ae10ed796b21fb5dfc9fd6953cb06db7aa6ae272fa8331c471b43eeb
76fb7fab42b98ecb28c3a4810707ae16ba609f70a9bff47d042c8a8d2ceb
05e3df81d4aabce9aec73f22a77f23fd124a5758a5950ebb73040aefc7c1
a8ff0021a1fbd9ff00b254a81c3a68afabe4346e6f4ec7a71a8f27dfb69c
8b7d9fd7caff00b7568752c776457f592867b7df4750ac11ab9843ec7fb7
feba932a3d43edf8b5eadeb5874e562b89d4dd8a1bebe37fdbadbbfeb492
9e7323a4595d9656d23f55c5af26f719ff000a2ab1ac6ffec5d34a27d5be
836f5dea4dc404d74346fc8b409d8c1f47e916fbed7fe8d9ff006e7f835a
ed7d97d03a97a2fc965d8ff61ead8ccd2ea9d4fa555594d63bf7bd3c7fa7
fe13d4ff00ad69fd52eafd13a630578b7e5655d94407e18a039f5107d36d
b6e456d6fab5319ff0ff00f59494f59d531e9c5fabd9b8f8ec15d55625cd
ad8386815bf6af1ce9dd432ba666559d88e0cbe92763880e1ee0ea9fed7f
ef56f5ed1d73fe44ea1ff856ff00fcf762f27faa3858b9ff00587131332b
16e3d9ea6fac9201db55d6b3e86dff0008c494da3f5ffeb41000ca6823b8
aab93a33c6bfe47fe0b67fc17a79fd01eeb3eb174f7bccb9d97539c7c49b
18e72f4fff00993f55e23ec0dd3f9767fe955e6dd2ea653f5b71aaac6d65
79ec6306ba06dbb5adf76e7a4a7d9963bb0fa97fce46658ea43ec469703d
348d6006b37b593eefd3d8cb9f95fceffda5fe6ac5b0b9e8fabeff00ae01
fead8eeb35d2582ad4d6c6edddbbe87f3be859fe95253d0a4924929f23fa
fdff008a5bff00aacffa95ce2e93ebff00fe29b23fa95ffd4b7cd6160d2c
c8cdc7c7b090cbad656e2d8061ce6b1db7724a4092f52ffc6dba07efe47f
9edf2ff824bff1b6e811f4f23fcf6ffe92494f96a4bd4bff001b6fabff00
bf91fe7b7ff4927ffc6dfeaf69eec8e67e98fe4fb7f9afe4a4a7cb125ea1
67f8b7e8018e707e402013f4dbd87fc52f31b5a196bd8386b8813e45253d
67f8b3ff0097eeff00c2afff00cf98ebd45797ff008b33fe5ebfcf15ff00
f9f31d779f587acd7d17a5db98e836416d0c3f9d611fa31fd5ff0049ff00
06929e2bfc6375df5f29bd1a9335639165e7fe1483b2bfec5762e254eeba
dbee7df738bedb1c5cf71ee4eae44c7c1ceca6976363db7b5a61c6b639e0
1fe57a6d724a76feaa7d63c1e806dbadc57e464dbed0e6b834359fbbee0f
4beb4fd61e9dd79ccbeac5b31f299a17b9c1c1cdfddfcddab2bf62f58ffb
8193ff006cbfff002097ec6eb1ff0070327fed9b3ff20929a4bb4ff173d7
3ecd98fe9173bf459477d13c36c68fd237febd5b3ff035c9e4606762b43f
2b1ada1ae30d758c73013f4b6b5d635a854db6516b2ea8edb2b707b0f839
a77b0a4a7d8beb67466f57e91752d137d63d4a0e9f4dbee6b7fb7fcd7fd7
2c5e36e6b98e2c782d73490e6910411f49ae6af6afabbd66aeb5d2e9cb69
02d8db7b3bb6c6fb5ffd977d3ad79dfd7be86ee9bd50e5d63f56cd25e23f
36c1fce877fc6ff3bff6ea4a63f51faf0e93d57d1bdc46266456ff0006be
7f437bbfced8f5eb2bc0576e3ebf387d58fb24b8f568f40d8663610e1f6b
f527f9dd9ff8324a737ebc75f3d57a99c7a1e4e1627b5827dafb07f3b91e
dffb6abffd48b9a4974bf513a29ea5d61b7d8d9c6c3fd238f6367f80afff
00477fd6bfe11253de7d4ee8aee8fd2195dc00c8b89b2ef273bf33fb35b2
b55bfc6198fab56f9db57fd57c574c000206802e6bfc6109fab371f0b2a3
ff004a1253e4c924bd0bea8fd53e81d53a1d1999743adbdce787bbd47b47
b5ce6b5bb6a7b3f31253e7a92f5cff00981f55ff00ee2bbfeddb3ff4a25f
f307eabffdc577fdbb67fe94494f91a4bd73fe607d57ff00b8aeff00b76c
ff00d2897fcc1faaff00f715dff6ed9ffa51253e46b67ea7ff00e29ba7ff
00c61ffa97af43ff00983f55ff00ee2bbfeddb3ff4aa3e0fd4de81819756
662d0e65f499638d8f7092367d1b1ee6fe724a73bfc64ffc80cff8f67e4b
1796af55ff0018cd07eaec9305b756479fd26af2a494fb47d5411f573a70
ff008169fbf55aeb27eaa907eae74e23fd0307dcb5925292492494a49249
2535fa862333b0afc3b090cbd8eadc4730e1b5789f54e9997d2b31f8796c
db633507b3da7e85b5ff0021ebdd155cfe9b81d4a9346750cbebec1e3569
e375767f3953ff00975a4a7c2925eab91fe2e7eae5c66b17e30f0aec91ff
00b34cc941ff00c6cba0ff00dc8cbff3ebff00de5494f9824bd3ff00f1b2
e85ff7232ffcfaff00f7992ffc6cba17fdc8cbff003ebffde6494f982704
b4820c11a823995e9dff008d9742ff00b9197fe7d7ff00bccb90fae1d030
ba167538d86fb2c6595ef71b4b490676fb7d2ae9494ed7d49fae395f6a67
49ea761babb7db8f7bcfbdaefcda6cb1ff00ce5767f835e8848682e2600d
492bc27a7bdd5e7e358dfa4cbab709f10e6b97a5fd7eebbf60e9430e87c6
4e682c31daa8fd3f6fcfdfe9ff00d71253c3fd6deb7fb6babbeeadc4e2d2
3d3c71a8f68fa766d9fa56bfff0003f496224add1d27aa64d42ec7c4bada
9d3b5ecadce698f6bb6b9ad494f49d07eba61f44e9cdc4a311ceb490eb6c
274718f77b377efac2ebbd4713a9e69ccc7a3eceeb07e95823693fbecd5e
a3fb03adcc7d8323fedb77fe452fd81d73fee064787f36effc8a4a73d7a8
7f8beeba33ba79e9b71fd630800c263df51fe6f6c06ff33b7d35e6993899
58967a5954be8b2376cb1a5a60fe76d7ab5d0faad9d23aa519cc98add16b
47e756ef6dace5bbbdbf43fe11253ee0bc87ebdffe29727e0cfc8bd63172
69ccc6ab2a876eaae687b1de4e1b9abca3ebe7fe29727faacffa9494e7fd
5c04f5dc003fd3b3f2ff00697b1f50e9f8bd4b15f8996c165560820ffd52
f1bfaba63aee07fc7b3f2af6e494f8d7d64fab597d0b2487036623cfe86e
ff00d156ff00c2ff00e7dffb72aaf14120c8d08e0af76cfc0c5ea18cfc5c
b60b2ab04105792fd66fab195d0b24900d984f23d2bbc09ddfa1b3f97ed4
94f53f537ebb7da4d7d2faabff004e7db4649fcff0aaf77fa6ff0085ff00
0bff0019fce770e82d33c415e04bbdfaadf5ef6d1fb3fabb8b9cd6c51926
35007b6ac873b6fbff0072eff09fe13f49fce253c12eeffc56ff003fd47f
a957e5b5708bbcff0015dfcf750fead5f96d494fa1a49249294924924a7f
ffd4efd2492494d3ead88dcde999588e98baa7b749e48f6fd15c97f8b3ca
2da33fa65836db4d82dda79f70f42ef6ff00c13e8aff00edc5dcaf37cf3f
f363ebd3330cb30b31dbec3260b2ef664b9fad8f7fa191fac7fd6d252fd4
f09f4e67d60e9267d4cadbd4709a3f38b5cebeee3feb8cff00ad27ad95e6
e49c9711e8fd64c33469a3599d536a735b638ec633d5beafd1ff00c3adaf
aeb83734627d62c268b2ce9c66f60126cc7711bb7387f81aff004bbffe0b
22db16007d258705973abc1ea2ff00b6f49ca100e3e4cbbd4c5b1cdf4767
e918fa59e9ff00337ff33fa7fd25694bd59797874559cea7f5be9a5dd37a
c5701ce7e3457f66b7e97f36c6633ff4b57f3bfe97fc2203853431bd31f7
3598a2dfb4747ea103730bbddf66b5fb9ecf43759ea6c7fe8edfd27e93fd
1deb5b9d9adfda0d635bd6711be9751c37437ed353363fed6c6b7db631fe
b53e9e4d7fccfa95fa9ea50b3f14b4d760c2a3f6860007ed1d36e245b411
b9f6594d7ecb18cfa6ff00d17f85ff000c929b5765371721d6e6fafd1bab
35a4599f4037519325a6af599fcbfa7ffa311adeb114c9fac38b508daeb3
1b10faee693bf6fe6ecffc0d361f5468afd2c0ea8cc7a58619d37aab37fa
665c1945393fd23d2655b2b57197f5864135745c5fdfbc1dda0fdda98fde
ff00dcff008c494ecfd5ab87ece7576b323ec712ccaea2e68b2f2fdcdbff
0040e73df5e333f45e97adfcefaca357d4ee9f89d7b1bac74f8c6151b3d6
c60258ef5196d5be8d7f57daebbf99fe63d3fe6bd1ff0009cbdb978d91d4
01befb3eb164b4fe870e96fa586cd03293b3f4957fa4ab7ffe7c5dbf4cea
7eb574e3675d8ffb55ec36598f413ed6cfb7f47639f6fb6bd9ea6fff000a
929d25e398023eb952008ff288d3febcbd8d798647d5dea1d23eb7615f73
43b1327398faaeac12c1baddeca2ddc3f457ecff0007ff006d7a8929f4f5
8fd1ddf6bcecdcdbba59c0c863cd0cc8781bf22b11fa4fa35bfd3fd1d5ff
0005fe8afb7f48aef5319eec0bdbd35cc666b9a450eb356877fafd051e8e
dea4de9b437aab9afce008b9cd882773b67d0dacfe6b624a6ea4924929f2
4ff181ff008a6bff00a95ffd4858dd23fe55c2ff00c3157fd5b1775f5afe
a5f56eb1d61f9d88ea1b5398c6c3dc5ae968daeddb2a72cec0ff00179d77
1b3f1b22c7e396536b2c7c3dc4c31cd7bbfc07f25253e96924924a524924
92985dfcd3ff00aa7f22f07c8fe916ff005ddf957bcbc6e696f88217995f
fe2e3af3eeb1ecb31f6b9ce2d97b81827fe252530ff16ba75fb89e062be7
fcfc743fafdd70751ea9f63a1fbb1b0fdb20e8eb0ff38ee7fc17f37ff6f2
d7e89f533eb17487e5e4576d1ebd98eea6987388dcf754edcfdf537dbb6b
5967fc5bfd62264bb1e4f3363bff004924a79400b886b44926001dcaf65f
aabd17f62f48af1dd1ebbff49791ddeeff00c833f46b9afab5f507370baa
5799d50d4eaa8f7d6c638ba6c07f46e7ee637db5fd3ff8c5dea4a5d24924
94e5fd62e8d575ae976e23f4b3e952f892d78f7376ff00d42f16b6a7d36b
eab06db2b716bda7b39a76b9abdf5709f5a7ea265f50ea4737a51a98db84
decb1c5bfa407f9c6fb6cfe71bfebfa4494e0fd45eb87a67566e35847d9b
348ade4cfb5fafa2f6ff0059ff00a35e85f59ba3b3acf49b7174f55a3d4a
1c7f36c68f67f9df41ff00f04b831fe2e3eb10321d8e08e3f48eff00d24b
d1ba3d59d4f4dc7a7a86d3955b032c731db83b6fb5b66f736bfa6929f0fb
2bb2ab1f55ad2cb2b716bda790e69daf6b9457a5fd6efa8f6752c83d47a5
96b725ff00cfd2f30d7c0dac7d2efa35d9ecd9fe8d723ff327eb44c7d81d
fe7d7ffa5525386c63ec7b58c6973dc435ad689249d1ad6b42f65faadd10
745e935e33e0e4389b2f70eef77fe419b2b585f553ea23ba7e437a87562c
7e4335a2869dcdaddfe9ad7fe7dccfccff00075ff39ff17db24a52c2fae9
83767fd5dcaaa86efb59b6d6b7c7639afb3ff01f516ea6494f80abd8bd6f
abe15228c4ccba9a4124318f21a09fa5b5abb9ebdfe2e6ac9b5f95d1ec6d
0f792e763593e949ff004163039f4ffc5ecb3feb4b07ff001bafac731b69
f8fa9ff9824a727fe737d61ffcb1c8ff00b71dfde9ff00e73fd6131fe51c
8d3fe11cb57ff1bafac7fbb4ff00db9ff98a6ffc6efeb27ee53ff6e0fee4
94e57fce6fac3ff96391a7fc2392ff009cbf580ffde8e46bff0008effc92
d5ff00c6ebeb27eed3ff006e7fe6290ff175f592636d23cfd4ff00cc5253
97ff0039beb0ff00e58e47fdb8ef8ad8faa3d7bace57d62c2c7c9cdbaea5
e5e1d5bde48315d85bbb77f510cff8bafac9fbb49ffae7fe62b5beacfd49
eb3d33ade2e765fa428a77976c7ee77b99654df6ecfde7a4a7a2faf18766
5fd5bca6d4ddd655b6d00730c735d67fe05bd78faf7e2038104483a10785
c3758ff16b564643efe9790dc76bc971c7b1a4b1a4ff00a1b2bfa157fc1f
a6929e4717eb67d60c3c7af171b31d5d150db5b0359a0feb1af7237fcf6f
ad1ff73ddfe657ff00a4568ffe369f583fd2e2ff009eff00fde74dff008d
afd60ff498dfe7bfff004824a73ffe7b7d68ff00b9eeff0032bf2ff82fe4
a6ff009ebf5a35fd7ddaff0022bffd24b47ff1b5fac1fe971bfcf7ff00e9
0487f8b5fac07fc2e30fedbfff004824a73bfe7afd6899fb7bbfccafff00
49271f5dbeb40007dbdda7f22b3e1ff05fc95a1ff8da7d60ff004b8bfe7b
ff00f79d3ffe369f583fd2e2ff009eff00fde7494cfeac7d6cebf99d730f
132b2cdb8f6bc87b1cd66bed73be9b58c7a87d69fac7d730beb0e6518b99
655554e68ad822002c63ff0039bfcb5a3f57bea1f58e9bd631b3f26da3d2
a1c5ce0c7b8b8fb5cdf6efa367e726fac5f51bacf53eb5959d8cea0537b8
1607bdc1da3595fb9ada9dfb8929e61df5afeb1b9c5c7a85b2798200ff00
35ad4dff003abeb17fe585df7ad6ff00c6dbeb0fefe37fdb8eff00d2297f
e36df587f7f1bfedc77fe91494e4ff00ceafac5ff96177f9c97fceafac5f
f96177dffec5adff008db7d61fdfc6ff00b71dff00a452ff00c6dbeb0fef
e37fdb8eff00d22929ca6fd6cfac6c3b8750b67cc83ff56d5473ba8e7751
b45d9b73afb0080e74682776df6ae8ff00f1b6fac3fbf8dff6e3bff48a3e
2ff8b2eacfb232f269a6a8fa55eeb1d33f47639b47fd5a4a799e8f8e6fce
add3b6ba3f4d6bcf0d6b0874bbfb49758ea77755ea16e65c492f30c07f35
a3e8b7fefebbcea5f516daba7370ba1bdad758672eebdc43ac681ecaff00
4553bf3961ff00e36bf583fd2637f9efff00d20929e7fa3f4bbfab750ab0
68d0d87dce890d68fa6f77faff0038bdaf0f16ac3c5ab169686d753435a0
7905cf7d4efaa6fe86cb6fccd8fcdb0ed0eac921b5fee6e7b59f9cba8494
a49249253c87f8c0e82337a71ea54b7f58c305ce8e5d569eaeeff8967e9b
ff00562f2f5efae6b5ed2c7096b8410bcdfa87f8b7ea8ecdb9f83651f657
38baa6bdce6b9ad2777a7b5b53ff009b494dcff173d78163ba3643a0b7dd
8b27904b9d6d7fd8ff005fe6960fd7d1ff0064b91e6d67fd4ad1c0fa83f5
9b07329cca6dc66d94bc387e91fdbe937f98fcf6fb15dfac7f527adf57ea
6ecea9f8ed0f63410e7381dcd1eee2ab1253c87d5cff0097b03fe3d9f957
b6af39e8ff00503ad61754c5cbbdf43aaa6c6bde18f717403f9ad752d5e8
c9294abe6e0e367e33f172ab1654f105a44ab0924a7c77eb37d56cbe8579
709b709e7f457784fd1aeffddb3ff3e7fe06b097bce4e2e3e5d2ea326b6d
b4bfe931e241fecae07abff8b4bfd636748b98697127d1b89059fc965ad6
bfd46ff5ff00f04494f08bd13fc5861dacc7cdcd708aed736b64f7f4f739
eeff00c1567607f8b5ea8fc86fed0b6aab1c105fe9b8bdee13eead9ed636
bdccff0009ff0081af45c3c4a30716ac4c66eca6968631be4047bbf79252
74924925292492494fffd5efd2492494a5cefd71fabffb67003a96ce5512
6b800b9c0fe67d2afe8bbfe37f45ebfa58f7647a2ba249253c4fd46ebedc
bc677d5fea91f68a41ae86583f9da8076fc67b5c366fc6637feb98ff00f1
36aa5d73eafd9d11f739949cbe8194e2eb6b6b775988e8f75f5ed6fe8eaa
ff00f3dfe86dff004ead7d74fab598fcc6758e9559f59bb5cef45bef1634
ef6dbb296fa9639ced9fa6fd259ea7f3ff00abfa7f67b7f567eba539db7a
6759fd5ba9b4fa44d836b6e77d18734b5adc7c9fccb287ff00396ff31fe8
2b4a7956b28af66464dd01e7f52eb1538bde1ccf4d8caba962fa9ec67a3e
9b3df57fe7dc8b16866e774dc80d1d76a0dcb869a3acf4f717b5cd9b18db
6cd59757edc67d5fa5f5ff00c35d554b77a9fd49acdb665f44b461db6c9b
319e3763d9a386cf4dbefc7dfea3ff004957f33fe02b5cf1e97d430722d3
66364748f697d97e334e4e14303ecb6fc8abf4be9d7b59eca9252ccc6bf2
e1b46474eeaf5b2093900559003bdbe86ff63bf33f9cfd27f38add7d1ac6
936b7eade2b9a0c6ff00b607301fe536c7bdbfb8a8330f1b2bda1dd2ba8b
5d1b6c16bb0b25c4ff00c138d2dffc06c55dfd1f258e34bba239dee2d6ed
c976d3f49ed6b7dfb5ff00a36bff00e33f9c494e8e465e46233d3bb2f0fa
456c6fb31ba682fc9b376e7fa3ebb7d5d9b9edfe777fa4aa62e25b5db464
b83fa6e33acdd53e77f50c971db51663318df56cb323f73d3fd0db917d5f
a3c3c94466259815d765b7607452c6877a95b9d7658247f37e935f7dbfa4
ddf9ecb7d0ff008dad6d61635b66f77d5fc1b6cc9b810eeb7d50969008f6
db8dbbf5cbbd467b3f56a29abf9af57d4494f598594ec8a2b7df57d9b21e
373b19ce6b9ecfdddfe9ff0023deacae7ba6f44c0e80d7f55ea7946dcc2d
8bf32f7c34076dfd0d5bb6edabd4fe6ebffd46a8e6752ea3f59aaa2efaab
9868fb35c5b955d9fa327567d9ef76966fc6f6dbfa3ff09fe87d4fd1a4a6
0f7e17d76c96d6d765603fa5d8e77006f92d6b5fba7f439357a7fb9fa25d
8a8535b995b4585aeb768163dadda1cefcf7867bb66e7ff2d11252924924
94a4924925292492494a4924925292492494a4924925292492494a492492
5292492494a4924925292492494a4924925292492494a492492529249249
4a4924925292492494a4924925292492494a4924925292492494a4924925
292492494a4924925292492494a4924925292492494a4924925292492494
a4924925292492494a4924925292492494a4924925292492494a49249253
ffd6efd2492494a492492529733f593ea5e17582ec9a00a33dc5bbac921a
e1f45fea57eef7ecff00b73fd257ea7aaba649253e6d8bd6beb5fd542313
3f1ce5e1b07b1af9f635a03dde865b03ff00475fa8c67bfed18f5ff3542e
8b03fc60fd5ecb6c5f63f0ec9036dad2419fddb71fd666cff8df4974b657
5dac2cb1a1ec772d70041f8b5cb0337ea3fd5ecb73de683558f2e71731c4
7b9dbb5d7fadfcdff36929b4f67d56eacf758efb0e6d80439ffa2b1e07fc
637758d556dfa9ff0054092fb312b6fc2db18381f9acbd8c5903fc57e0ef
797e6d9b4ba58d630376b7f71ceb1f77a8ff00e5ff00e069bff1aec2db1f
6fb77763b1b1f9bf9bbbfaff00ebfce253aaec8fa8bd208b9a706bb2b300
d6196dad274fa340bf2566753ff1958cddd4f48c67e4dba86db68dacd3fc
232967e9ed67f5fecc9b1bfc5860b2c71cacdb2da88f636b60aded33eddd
6bdf935bff00ed85d1e1fd59e8585b0d3875ef6410f70dcedc07a7ea7bfd
bbd253c4e3fd5dfac9f5b6d19dd5720d147f822f69da1ae1bb76163b7654
fabf99fd2eff00d3ff00dc8f51779d1fa360f46c46e2e1b600fa763a37d8
7f7ed7abc9d25292492494a4924925292492494a4924925292492494a492
4925292492494a4924925292492494a4924925292492494a492492529249
2494a4924925292492494a4924925292492494a4924925292492494a4924
925292492494a4924925292492494a4924925292492494a4924925292492
494a4924925292492494a4924925292492494a4924925292492494a49249
25292492494a4924925292492494ff00ffd7efd2492494a4924925292492
494a4924925292492494a4924925292492494a4924925292492494a49249
25292492494a4924925292492494a4924925292492494a49249252924924
94a4924925292492494a4924925292492494a4924925292492494a492492
5292492494a4924925292492494a4924925292492494a492492529249249
4a4924925292492494a4924925292492494a4924925292492494a4924925
292492494a4924925292492494a4924925292492494a49249253ffd9
]]></icerik></resim><kisa_ad>Resim 3d1df48649498</kisa_ad><kaynak>TKWORD</kaynak><gizlilik>TASNIF DISI</gizlilik><tarihce islemturu="YENI_KAYIT"><kullanici>havelsan</kullanici><islemani>2002-06-29T20:55:18</islemani></tarihce></nesne> -
Fact and dimension table partition
My team is implementing new data-warehouse. I would like to know that when should we plan to do partition of fact and dimension table, before data comes in or after?
Hi,
It is recommended to partition Fact table (Where we will have huge data). Automate the partition so that each day it will create a new partition to hold latest data (Split the previous partition into 2). Best practice is to create partition on transaction
timestamps so load the incremental data into a empty table called (Table_IN) and then Switch that data into main table (Table). Make sure your tables (Table and Table_IN) should be on one file group.
Refer below content for detailed info
Designing and Administrating Partitions in SQL Server 2012
A popular method of better managing large and active tables and indexes is the use of partitioning. Partitioning is a feature for segregating I/O workload within
SQL Server database so that I/O can be better balanced against available I/O subsystems while providing better user response time, lower I/O latency, and faster backups and recovery. By partitioning tables and indexes across multiple filegroups, data retrieval
and management is much quicker because only subsets of the data are used, meanwhile ensuring that the integrity of the database as a whole remains intact.
Tip
Partitioning is typically used for administrative or certain I/O performance scenarios. However, partitioning can also speed up some queries by enabling
lock escalation to a single partition, rather than to an entire table. You must allow lock escalation to move up to the partition level by setting it with either the Lock Escalation option of Database Options page in SSMS or by using the LOCK_ESCALATION option
of the ALTER TABLE statement.
After a table or index is partitioned, data is stored horizontally across multiple filegroups, so groups of data are mapped to individual partitions. Typical
scenarios for partitioning include large tables that become very difficult to manage, tables that are suffering performance degradation because of excessive I/O or blocking locks, table-centric maintenance processes that exceed the available time for maintenance,
and moving historical data from the active portion of a table to a partition with less activity.
Partitioning tables and indexes warrants a bit of planning before putting them into production. The usual approach to partitioning a table or index follows these
steps:
1. Create
the filegroup(s) and file(s) used to hold the partitions defined by the partitioning scheme.
2. Create
a partition function to map the rows of the table or index to specific partitions based on the values in a specified column. A very common partitioning function is based on the creation date of the record.
3. Create
a partitioning scheme to map the partitions of the partitioned table to the specified filegroup(s) and, thereby, to specific locations on the Windows file system.
4. Create
the table or index (or ALTER an existing table or index) by specifying the partition scheme as the storage location for the partitioned object.
Although Transact-SQL commands are available to perform every step described earlier, the Create Partition Wizard makes the entire process quick and easy through
an intuitive point-and-click interface. The next section provides an overview of using the Create Partition Wizard in SQL Server 2012, and an example later in this section shows the Transact-SQL commands.
Leveraging the Create Partition Wizard to Create Table and Index Partitions
The Create Partition Wizard can be used to divide data in large tables across multiple filegroups to increase performance and can be invoked by right-clicking
any table or index, selecting Storage, and then selecting Create Partition. The first step is to identify which columns to partition by reviewing all the columns available in the Available Partitioning Columns section located on the Select a Partitioning Column
dialog box, as displayed in Figure 3.13. This screen also includes additional options such as the following:
Figure 3.13. Selecting a partitioning column.
The next screen is called Select a Partition Function. This page is used for specifying the partition function where the data will be partitioned. The options
include using an existing partition or creating a new partition. The subsequent page is called New Partition Scheme. Here a DBA will conduct a mapping of the rows selected of tables being partitioned to a desired filegroup. Either a new partition scheme should
be used or a new one needs to be created. The final screen is used for doing the actual mapping. On the Map Partitions page, specify the partitions to be used for each partition and then enter a range for the values of the partitions. The
ranges and settings on the grid include the following:
Note
By opening the Set Boundary Values dialog box, a DBA can set boundary values based on dates (for example, partition everything in a column after a specific
date). The data types are based on dates.
Designing table and index partitions is a DBA task that typically requires a joint effort with the database development team. The DBA must have a strong understanding
of the database, tables, and columns to make the correct choices for partitioning. For more information on partitioning, review Books Online.
Enhancements to Partitioning in SQL Server 2012
SQL Server 2012 now supports as many as 15,000 partitions. When using more than 1,000 partitions, Microsoft recommends that the instance of SQL Server have at
least 16Gb of available memory. This recommendation particularly applies to partitioned indexes, especially those that are not aligned with the base table or with the clustered index of the table. Other Data Manipulation Language statements (DML) and Data
Definition Language statements (DDL) may also run short of memory when processing on a large number of partitions.
Certain DBCC commands may take longer to execute when processing a large number of partitions. On the other hand, a few DBCC commands can be scoped to the partition
level and, if so, can be used to perform their function on a subset of data in the partitioned table.
Queries may also benefit from a new query engine enhancement called partition elimination. SQL Server uses partition enhancement automatically if it is available.
Here’s how it works. Assume a table has four partitions, with all the data for customers whose names begin with R, S, or T in the third partition. If a query’s WHERE clause
filters on customer name looking for ‘System%’, the query engine knows that it needs only to partition three to answer
the request. Thus, it might greatly reduce I/O for that query. On the other hand, some queries might take longer if there are more than 1,000 partitions and the query is not able to perform partition elimination.
Finally, SQL Server 2012 introduces some changes and improvements to the algorithms used to calculate partitioned index statistics. Primarily, SQL Server 2012
samples rows in a partitioned index when it is created or rebuilt, rather than scanning all available rows. This may sometimes result in somewhat different query behavior compared to the same queries running on SQL Server 2012.
Administrating Data Using Partition Switching
Partitioning is useful to access and manage a subset of data while losing none of the integrity of the entire data set. There is one limitation, though. When
a partition is created on an existing table, new data is added to a specific partition or to the default partition if none is specified. That means the default partition might grow unwieldy if it is left unmanaged. (This concept is similar to how a clustered
index needs to be rebuilt from time to time to reestablish its fill factor setting.)
Switching partitions is a fast operation because no physical movement of data takes place. Instead, only the metadata pointers to the physical data are altered.
You can alter partitions using SQL Server Management Studio or with the ALTER TABLE...SWITCH
Transact-SQL statement. Both options enable you to ensure partitions are
well maintained. For example, you can transfer subsets of data between partitions, move tables between partitions, or combine partitions together. Because the ALTER TABLE...SWITCH statement
does not actually move the data, a few prerequisites must be in place:
• Partitions must use the same column when switching between two partitions.
• The source and target table must exist prior to the switch and must be on the same filegroup, along with their corresponding indexes,
index partitions, and indexed view partitions.
• The target partition must exist prior to the switch, and it must be empty, whether adding a table to an existing partitioned table
or moving a partition from one table to another. The same holds true when moving a partitioned table to a nonpartitioned table structure.
• The source and target tables must have the same columns in identical order with the same names, data types, and data type attributes
(length, precision, scale, and nullability). Computed columns must have identical syntax, as well as primary key constraints. The tables must also have the same settings for ANSI_NULLS and QUOTED_IDENTIFIER properties.
Clustered and nonclustered indexes must be identical. ROWGUID properties
and XML schemas must match. Finally, settings for in-row data storage must also be the same.
• The source and target tables must have matching nullability on the partitioning column. Although both NULL and NOT
NULL are supported, NOT
NULL is strongly recommended.
Likewise, the ALTER TABLE...SWITCH statement
will not work under certain circumstances:
• Full-text indexes, XML indexes, and old-fashioned SQL Server rules are not allowed (though CHECK constraints
are allowed).
• Tables in a merge replication scheme are not allowed. Tables in a transactional replication scheme are allowed with special caveats.
Triggers are allowed on tables but must not fire during the switch.
• Indexes on the source and target table must reside on the same partition as the tables themselves.
• Indexed views make partition switching difficult and have a lot of extra rules about how and when they can be switched. Refer to
the SQL Server Books Online if you want to perform partition switching on tables containing indexed views.
• Referential integrity can impact the use of partition switching. First, foreign keys on other tables cannot reference the source
table. If the source table holds the primary key, it cannot have a primary or foreign key relationship with the target table. If the target table holds the foreign key, it cannot have a primary or foreign key relationship with the source table.
In summary, simple tables can easily accommodate partition switching. The more complexity a source or target table exhibits, the more likely that careful planning
and extra work will be required to even make partition switching possible, let alone efficient.
Here’s an example where we create a partitioned table using a previously created partition scheme, called Date_Range_PartScheme1.
We then create a new, nonpartitioned table identical to the partitioned table residing on the same filegroup. We finish up switching the data from the partitioned table into the nonpartitioned table:
CREATE TABLE TransactionHistory_Partn1 (Xn_Hst_ID int, Xn_Type char(10)) ON Date_Range_PartScheme1 (Xn_Hst_ID) ; GO CREATE TABLE TransactionHistory_No_Partn (Xn_Hst_ID int, Xn_Type
char(10)) ON main_filegroup ; GO ALTER TABLE TransactionHistory_Partn1 SWITCH partition1 TO TransactionHistory_No_Partn; GO
The next section shows how to use a more sophisticated, but very popular, approach to partition switching called a sliding
window partition.
Example and Best Practices for Managing Sliding Window Partitions
Assume that our AdventureWorks business is booming. The sales staff, and by extension the AdventureWorks2012 database, is very busy. We noticed over time that
the TransactionHistory table is very active as sales transactions are first entered and are still very active over their first month in the database. But the older the transactions are, the less activity they see. Consequently, we’d like to automatically group
transactions into four partitions per year, basically containing one quarter of the year’s data each, in a rolling partitioning. Any transaction older than one year will be purged or archived.
The answer to a scenario like the preceding one is called a sliding window partition because
we are constantly loading new data in and sliding old data over, eventually to be purged or archived. Before you begin, you must choose either a LEFT partition function window or a RIGHT partition function window:
1. How
data is handled varies according to the choice of LEFT or RIGHT partition function window:
• With a LEFT strategy, partition1 holds the oldest data (Q4 data), partition2 holds data that is 6- to 9-months old (Q3), partition3
holds data that is 3- to 6-months old (Q2), and partition4 holds recent data less than 3-months old.
• With a RIGHT strategy, partition4 holds the holds data (Q4), partition3 holds Q3 data, partition2 holds Q2 data, and partition1
holds recent data.
• Following the best practice, make sure there are empty partitions on both the leading edge (partition0) and trailing edge (partition5)
of the partition.
• RIGHT range functions usually make more sense to most people because it is natural for most people to to start ranges at their lowest
value and work upward from there.
2. Assuming
that a RIGHT partition function windows is used, we first use the SPLIT subclause of the ALTER PARTITION FUNCTIONstatement
to split empty partition5 into two empty partitions, 5 and 6.
3. We
use the SWITCH subclause
of ALTER TABLE to
switch out partition4 to a staging table for archiving or simply to drop and purge the data. Partition4 is now empty.
4. We
can then use MERGE to
combine the empty partitions 4 and 5, so that we’re back to the same number of partitions as when we started. This way, partition3 becomes the new partition4, partition2 becomes the new partition3, and partition1 becomes the new partition2.
5. We
can use SWITCH to
push the new quarter’s data into the spot of partition1.
Tip
Use the $PARTITION system
function to determine where a partition function places values within a range of partitions.
Some best practices to consider for using a slide window partition include the following:
• Load newest data into a heap, and then add indexes after the load is finished. Delete oldest data or, when working with very large
data sets, drop the partition with the oldest data.
• Keep an empty staging partition at the leftmost and rightmost ends of the partition range to ensure that the partitions split when
loading in new data, and merge, after unloading old data, do not cause data movement.
• Do not split or merge a partition already populated with data because this can cause severe locking and explosive log growth.
• Create the load staging table in the same filegroup as the partition you are loading.
• Create the unload staging table in the same filegroup as the partition you are deleting.
• Don’t load a partition until its range boundary is met. For example, don’t create and load a partition meant to hold data that is
one to two months older before the current data has aged one month. Instead, continue to allow the latest partition to accumulate data until the data is ready for a new, full partition.
• Unload one partition at a time.
• The ALTER TABLE...SWITCH statement
issues a schema lock on the entire table. Keep this in mind if regular transactional activity is still going on while a table is being partitioned.
Thanks Shiven:) If Answer is Helpful, Please Vote -
Please help to a newcomer to XML:
I intend to create XML based database of documents and present
it on Web.
Documents are of fixed structure however few elements will be up
to ;K of size. They will be static.
Total size of a document is less then 4K, expect some 10,000+
entries ?
Need to
- Search in DB by keywords and also support free search in
documents. Once found and selected,full document is displayed.
- Create discussion topic with threads, where contributions may
have pointers to selected elements of these documents and these
links are higlighted.
Please advise how to work on it and also how to handle inserts
into DB.
- Should one store the whole documents including element tags as
CLOB ?
Data will be prepared from scratch so my though is to
prepare some templates to be used by a XML editor to prepare
XML files. Create DTD (or use an existing one) and use parser
(which one is suitable?) to validate correctness.
Q1: Some elements ttheoreticallyv ask for being handled as
attributes. There are, however some 50+ possible values and I
donFt think a DTD should be prepared to handle this by itself!
Is this appropirate ?
Q2: How to insert data ? Are there tools available or should
one process data using Java or PL/SQL and then insert into
appropriate tables?
Q3: Use interMedia to search DB, then XSQL to retrieve relevant
data and present via XSL ?
Thanks !
Peter
nullHi,
Thank you for your answer,
Actually this is the way I'm doing the merge process today: using Java code with DOM to merge all documents to one XML document.
I'm looking for ways to not using the DOM parsing becasue it is very expensive in CPU and memory (DOM is the worst XML parser in a performance point of view).
SAX parsing is also not appropriate because the merge process that I need to do is vey complicated.
This is the reason why I thought of using XSLT.
My question is if XSLT can do the work or is it way off?
Thanks, -
Import Large XML File to Table
I have a large (819MB) XML file I'm trying to import into a table in the format:
<ROW_SET>
<ROW>
<column_name>value</column_name>
</ROW>
<ROW>
<column_name>value</column_name>
</ROW>
</ROW_SET>
I've tried importing it with xmlsequence(...).extract(...) and ran into the number of nodes exceed maximum error.
I've tried importing it with XMLTable(... passing XMLTYPE(bfilename('DIR_OBJ','large_819mb_file.xml'), nls_charset_id('UTF8'))) and I gave up after it ran for 15+ hours ( COLLECTION ITERATOR PICKLER FETCH issue ).
I've tried importing it with:
insCtx := DBMS_XMLStore.newContext('schemaname.tablename');
DBMS_XMLStore.clearUpdateColumnList(insCtx);
DBMS_XMLStore.setUpdateColumn(insCtx,'column1name');
DBMS_XMLStore.setUpdateColumn(insCtx,'columnNname');
ROWS := DBMS_XMLStore.insertXML(insCtx, XMLTYPE(bfilename('DIR_OBJ','large_819mb_file.xml'), nls_charset_id('UTF8')));
and ran into ORA-04030: out of process memory when trying to allocate 1032 bytes (qmxlu subheap,qmemNextBuf:alloc).
All I need to do is read the XML file and move the data into a matching table in a reasonable time. Once I have the data in the database, I no longer need the XML file.
What would be the best way to import large XML files?
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
"CORE 11.2.0.1.0 Production"
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionThis (rough) approach should work for you.
CREATE TABLE HOLDS_XML
(xml_col XMLTYPE)
XMLTYPE xml_col STORE AS SECUREFILE BINARY XML;
INSERT INTO HOLDS_XML
VALUES (xmltype(bfilename('DIR_OBJ','large_819mb_file.xml'), nls_charset_id('UTF8')))
-- Should be using AL32UTF8 for DB character set with XML
SELECT ...
FROM HOLD_XML HX
XMLTable(...
PASSING HX.xml_col ...)How it differs from your approach.
By using the HOLDS_XML table with SECUREFILE BINARY XML storage (which became the default in 11.2.0.2) we are providing a place for Oracle to store a parsed version of the XML. This allows the XML to be stored on disk instead of in memory. Oracle can then access the needed pieces of XML from disk by streaming them instead of holding the whole XML in memory and parsing it repeatedly to find the information needed. That is what COLLECTION ITERATOR PICKLER FETCH means. A lot of memory work. You can search on that term to learn more about it if needed.
The XMTable approach then simply reads this XML from disk and should be able to parse the XML with no issue. You have the option of adding indexes to the XML, but since you are simply reading it all one time and tossing it, there is no advantage to indexes (most likely)
Maybe you are looking for
-
How do I branch to a dynamic page on the App Server
I have a dynamic page that is a menu that is dynamically generated based on what choice was selected from a higher level menu that is a portlet on the front page of our site (Application Server based). This menu calls up application code, currently a
-
want to know amount detalis for vendor vendor creation involves purchase organization , account etc. when a vendor do some finicial transaction then that amount is stored in some table . Can we find out the transaction ( amount ) done by vendor us
-
New Aluminum owner... My display keeps dimming itself while I am working. I've checked the energy settings, brightness controls, display settings, and I can't find any "auto dimmer" setting. Does the same thing on battery or power adapter. If I want
-
No mail after roll up 4 for Exchange Server 2010 SP3 KB2905616
Hi Exchange 2010 on SBS 2011. After auto application of roll up 4 thee are no emails. Although all exchange services are running. Restarting server did no help. Running mail trouble shooter comes up with 'Server Does Not Support Secure Connections'.
-
Hi, I've been having some issues with my gx740 lately. Once a while, when im playing a game, League of Legends to be exact, top of the screen flickers, like the very top, 1 cm ish or so. When that happens, i lag, and it continues for about 3-5 second