View Full Version : create table abc/xyz as und XML
Moin zusammen,
Excel kann ja XML lesen!, Ohne definitionen.
Kann die I das auch? ohne 150 Felder zu definieren?
create table LIB/FILE as(
select * from xmltable('/AAAA/BBB/' passing xmlparse(document get_xml_file('....
Wenn ja, wie ist die Syntax?
Wenn nein, Warum nicht?
Danke
der ILEMax
Andreas_Prouza
26-11-20, 09:05
Mit Boardmitteln ist mir da leider nichts bekannt wenn du jetzt SQL meinst.
Auf der IBM i kannst du ja auch mit anderen Sprachen arbeiten.
Mit Java, PHP oder Python auf der IBM i kannst du das ganz einfach.
lg Andreas
Dazu bedarf es keines Create Table. Denn wozu eine Tabelle erstellen, die 1-malig die Daten aus der XML kopiert?
Du kannst direkt XML als embedded SQL verarbeiten.
Alle Informationen findest du hier:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzasp/rzaspkickoff.htm
XML kann man doch nicht ernsthaft lesen!
Da auch in aller letzten Abschnit noch ein Extra kommen kann, ist das für unsere Schnittstellen eine Zumutung!
Wenn der Schnittstellen Partner keine definitionen liefert, da er die Daten 'aus seinem System mit einem Menüpunkt' erzeugt, wäre uns eine Datei die alles was (in jeder Lieferung neu ) möglich ist, in einem Satz zur Verfügung stellt. Routinen die eine PF auswerten und verarbeiten haben wir genug. Excel auch,
und da Excel die daten einfach einliest,wäre es für die I halt ganz nett.
So gehen wir immer dem Umweg über Excel.
Das ist doch kein Hexenwerk.
Es gibt genug XML-Viewer um Strukturen zu erkennen, Birgitta hat schon viele Beispiele bzgl. XPath geliefert und mittels XML-INTO lassen sich auch (fast) alle XML's problemlos per geschachtelter qualified Strukturen einlesen und genauso leicht wie eine PF verarbeiten.
Also ich habe mit XML-INTO schon sehr schöne Ergebnisse erreicht.
Klar können das ander, objektorientierte, Sprachen besser.
Aber mit XML-INTO kann ich auch durch Pfadangaben ähnlich wie SQL gezielte Strukturen auslesen.
Und Felder, die ich nicht benötige, muss ich auch nicht definieren.
XML und JSON sind halt die zur Zeit gängigen Strukturen.
Es ist ja nicht so wie bei DATEV, die für Im- und Export immer noch nur CSV und EXCEL können.