Excel in db/400 lesen

[dibe]

Hallo *all

wir haben hier ein Tool(gekauft), das Excel in AS/400 Datenbank Dateiein umwandelt.
Aber das braucht für ca. 2000 Sätze (ca 40 Spalten) über 30 Sekunden.

Wenn ich mir vorstelle wie lange es dann bei 87.000 Sätzen läuft ...

Habt Ihr Tools im Einsatz? Wie schnell sind die?
Oder gibt es Bordmittel (außer die CSV Variante)
Einen Java Entwickler haben wir auch, der meinte er könne Das zwar auch, aber warscheinlich nicht schneller!

Ist das 'Normal'
Dietlinde Beck

[BenderD]

... was ist schon normal? 70 Sätze in der Sekunde kann je nach Hardware, Komplexität des Excels und eingesetzter Technologie langsam, normal oder schnell sein; für eine Einschätzung ob da Optimierungspotential besteht bräuchte man schon ein paar Informationen mehr.

D*B

[dibe]

Na ja, es ist eine 520 mit v7R1, alle PTF
Es ist ein Excel mit ca 2000 Zeilen, ca 40 Spalten, überwiegend Datum oder 2 Stellige Felder, bischen Text. Und teilweise verweisen die Zellen aufeinander ( Inhalt = injhalt zelle x + inhalt zelle y)
Den Toolnamen möchte ich nin nennen, wil ja niemanden schlecht machen, erst recht nicht, wenn das 'normal' ist. Die Datei steht im IFS, das Tool läuft auf der iSeries.Welche Infos fehlen noch?
DiBe

[Fuerchau]

Für normal würde ich das nicht halten.
Probier doch mal mein Upload/400, dass ist ein AddIn direkt für Excel.
Die Komplexität von Excel sollte da keine Rolle spielen.

Frage doch mal beim Toolhersteller nach, warum das so lange braucht.

[dibe]

Upload/400 können wir (warscheinlich) nicht gebrauchen. Wir müssen von der AS400 Excel Daten holen, nicht vom PC Daten senden. Schön wär halt wenn man einen vergleich hätte, auch wenn das natürlich von der HW abhängig ist.
DiBe

[andreaspr@aon.at]

Du könntest auch mal einen DB Monitor mitlaufen lassen.
Dann siehst du eventuell ob die DB Zugriffe das Problem sein könnten (auch wenn eher unwahrscheinlich).
Aber vielleicht lässt sich zumindest da irgendetwas "herauslesen".
Z.B. Ob:
* die Daten zwar schnell in die DB geschrieben werden, aber dazwischen längere Pausen gibt
* Das PGM anfangs lange braucht, die 2000 Sätze aber schnell in die DB geschrieben hat
Je nach dem welche Technologie verwendet wird, kann das auch auf ein Konfigurationsproblem hinweisen.
(Beispiel: QSH, PHP)
* usw.

lg Andreas

[BenderD]

... man muss das Tool ja nicht namentlich outen, aber es gibt da schon wesentliche Unterschiede:
- ist das Java basiert (wenn es komplexere Excels kann, ist das wahrscheinlich!)
- liest es das Excel erst komplett ein und arbeitet es dann weiter, oder arbeitet es Zeilenweise (bei a verwendet es HSSF bei b JEXCEL o.ä.)
- hat das noch einen RPG JNI wrapper dazwischen (Scott Clement's oder eigenen wrapper)
Wenn da ein paar Sachen zusammenkommen, könnte man das schon noch entscheidend beschleunigen (allerdings nicht mit diesem Tool, da müssten alternative Konzepte ran).
Interessant wäre noch ein zeitliches Profil (kriegt man auch ohne DBMON ziemlöich einfach, indem man im Abstand von 30 sec. jeweils mit DSPFD *MBRLIST ermittelt wieviele Sätze geschrieben wurden).

D*B

[Fuerchau]

Ich glaube kaum, dass das Tool die Formeln nachrechnet.
Wenn Excel die Berechnungen durchgeführt hat, stehen die Ergebnisse in den Zellen.
Nun kommt es auf das Tool an, wie schnell die Daten aus Excel extrahiert werden.
Auch bei langsameren AS/400 ist das Schreiben in die DB sehr effektiv.
Dies kann man auch ohne DB-Monitor mit einem einfachen CPYF oder per SQL mit "insert ... select ..." testen.
Raten von mehr als 1000 Sätze/Sekunde sind durchaus üblich.
Die Zeit wird in dem Tool verbraten.

Ggf. ist dies Java basiert, hier könnte man mal prüfen welche JVM zur Ausführung kommt. Da stehen immerhin mehrere zur Auswahl.

[dibe]

Danke, ich geb das mal weiter,
Was ggf nicht so richtig von mir beschrieben ist, ist die Tatsache das es die AS400 Datei nicht gibt!
Das Tool ermittelt selbstständig ob es ein Num oder Alpa Feld ist, wie lang es ist und erzeugt die AS400 Datei!
@MK
Ich frag mal on ich die Datei rausgeben darf, wenn ja schicke ich Sie Ihnen
DiBe

[Fuerchau]

Diese Analyse kann da schon mal dauern.
Ggf. analysiert das Tool erst alle Zeilen auf die beste Felddefinition, liest also alles, erstellt dann die Datei und liest und exportiert nun alles.
Vielleicht kann man dem Tool ja mitteilen, dass es nur ein paar Zeilen prüfen soll (wie Excel z.B. beim CSV-Import).

Ich brauch die Datei nicht, habe auch keine AS/400 und auch nicht das unbekannte Tool.

[BenderD]

Diese Analyse kann da schon mal dauern.
Ggf. analysiert das Tool erst alle Zeilen auf die beste Felddefinition, liest also alles, erstellt dann die Datei und liest und exportiert nun alles.
Vielleicht kann man dem Tool ja mitteilen, dass es nur ein paar Zeilen prüfen soll (wie Excel z.B. beim CSV-Import).

Ich brauch die Datei nicht, habe auch keine AS/400 und auch nicht das unbekannte Tool.

... ich gehe mal davon aus, dass das Java basiert ist (POI oder JExcel); dabei wird das ganze workbook (POI) oder Sheet (JExcel) komplett eingelesen, was insbesondere aus RPG über JNI aufgerufen immensen Overhead erzeugt (ein klassischer Kunstfehler). Dann sind im Prinzip das Format der Columns und die Länge bekannt (bei Overrides für Einzelzellen oder Bereiche gibt es so oder so Randprobleme).
Die Komplexität des Excels (gibt es unterschiedliche Formatierungen für überlappende Bereiche etc.) wirkt sich schon auf die Verarbeitungszeit aus, einmal über die Größe, aber auch über die eventuell auftretenden Randprobleme (was passiert, wenn da auf einmal eine Grafik auftaucht...).

@OP: Entscheidenden Perfomancegewinn kriegt man hier über prestarted JVM mit preloaded POI/JExcel (AppServer4RPG ist Dein Freund), diese Variante öffnet auch den Weg die Verarbeitung transparent im Netzwerk zu verlagern, sprich: für die native RPG Welt sieht das alles lokal aus, die Workload kann aber auf einen Rechner verlagert werden, der CPU Power und Hauptspeicher wesentlich billiger bereitstellt; das bringt Zeitgewinn und vermeidet Ressourcen Engpässe.

D*B