AS400 Daten => Windows als EXCEL

[alex61]

Hallo zusammen,
folgende Frage an die Profis :
wie kann ich von der AS400 aus Daten aus einem PF nach Windows kopieren und dort als EXCEL ablegen ? Natürlich geht das mit dem File-Transfer, keine Frage. Aber ich bräuchte das irgendwie automatisiert. Oder kann man den File-Transfer auch irgendwie automatisieren ? Oder gibt es eine noch einfachere Lösung. Hat da jemand evtl. ein Beispiel wie das mit einem automatisierten File-Transfer geht ? Ich habe derzeit leider keinen Plan.

Für Infos bin ich wie immer dankbar.
Gruß A.

[B.Hauser]

Am einfachsten ist es m.E. man verwendet die skalare SQL Funktion GENERATE_SPREADSHEET in der Bibliothek SYSTOOLS
GENERATE_SPREADSHEET

Values(Systools.Generate_Spreadsheet(Path_Name         => '/Home/.../YourSelect', 
                                     Spreadsheet_Query => 'Select * from ...', 
                                     Spreadsheet_Type  => 'xlsx', 
                                     Column_Headings   => 'COLUMN')); 

bzw.

Values(Systools.Generate_Spreadsheet(Path_Name         => '/Home/.../YourFile', 
                                     Library_Name      => 'YOURSCHEMA',
                                     File_Name         => 'YOURTABLE',
                                     Spreadsheet_Type  => 'xlsx', 
                                     Column_Headings   => 'COLUMN')); 

Dann muss es nur noch aus dem IFS auf den PC übertragen werden.

[Fuerchau]

Man kann auch den umgekehrten Weg gehen, da Excel via ODBC Daten auch selber direkt formatiert und typgerecht laden kann.
Vorteil:
Da die Informationen, Verbindung und SQL, in der Excel vorhanden sind, kann man die Daten jederzeit aktualisieren.

Wenn man Sicherheitsbedenken hat, kann man für solche Dinge auch eine Lib mit zugeschnittenen Views bereitstellen, auf die die User dann zum Lesen berechtigt sind.

Denn das Hauptproblem ist spätestens dann, wenn man u.U. per WRKLNK eine QNTC-Verbindung zum Windows-Server macht und dieser nicht erreichbar ist. Ist schließlich Windows.
Statt QNTC geht dann wieder nur FTP, und da wird dann häufig auch SFTP verlangt.

Ach ja und:
Für QNTC muß auf dem Windows-PC ein lokaler User erstellt sein, dessen Name max. 10 stellig mit dem AS/400-User identlisch sein muss und das Passwort mus den Richtlinien der AS/400 entsprechen, die bei Windows häufig höher in den Anforderungen sind, und identisch sein.
Und nur dieser User kann dann auf QNTC zugreifen, denn adopted Authority klappt weder beim IFS und schon gar nicht bei QNTC.

[alex61]

besten Dank an alle Helfenden !! Bin sehr dankbar für die Tipps und sollte nun klar kommen.

[Pikachu]

Such mal nach „RTOPCB“.

[Fuerchau]

Wie immer gibts viele Lösungen:
https://developer.ibm.com/articles/i-acs-commandline/
Aber die Einfachste ist wirklich, es Excel selber machen zu lassen.

Wie war das nochmal mit Bring- und Holschuld?
Information ist eine Holschuld.

[camouflage]

Baldur, die ACS Lösung funktioniert auch gut, nur ist sie ziemlich langsam. Den SQL Ansatz schau ich mir mal an, der tönt vielversprechend.

[Fuerchau]

Das Problem ist doch immer, dass man mit den Daten in Excel ja weiterarbeiten will.
Wenn du die Abfrage direkt mit Excel machst, kannst du das Ziel direkt festlegen.
Mit den anderen Mitteln erhältst du immer eine neue Excel und musst die Daten in dein Arbeitsblatt hineinkopieren.
Durch den direkten Import in Excel kannst du z.B. die Überschriften weglassen um eigene Überschriften darüber zu setzen.
Der importierte Bereich erhält einen Namen "Abfrage n", auf den man z.B. in einem Chart bezugnehmen kann. Aktualisiere ich die Daten, verändert sich ggf. der Bereich, wird kürzer oder länger, und somit verändert sich auch das Chart.
Ich kann auch rechts neben den geladenen Daten bereits Formeln eintragen, die etwas damit rechnen.
Vorbereitet habe ich die Überschriften als Filter.

Man kann ebenso die Daten auch direkt in ein Chart oder eine Pivot laden.
Da gibts dann auf wiederum Exportmöglichkeiten in andere Arbeitsblätter von Teilen der geladenen Teile.
Ich kann berechnete Felder im Chart hinzufügen, die bei Aktualisierungen auch erhalten bleiben.

Alles das geht verloren, wenn ich die Daten immer erst aus einer anderen Excel importieren muss.
Dies könnte ich auch via ODBC oder externem Link. Macht die Sache aber nicht einfacher.

Wer dauernd empfielt, mach das doch mit SQL, kennt wohl Excel nicht gut genug um die Vorteile des Imports mit Aktualisierungsfunktion zu kennen.
Tut mir leid, wenn ich da jemanden mit auf die Füße trete, aber ich empfehle meinen Kunden immer den Import, was sich hinterher auch immer als die bessere Lösung bewiesen hat.

[BenderD]

Das Problem ist doch immer, dass man mit den Daten in Excel ja weiterarbeiten will.
Wenn du die Abfrage direkt mit Excel machst, kannst du das Ziel direkt festlegen.
Mit den anderen Mitteln erhältst du immer eine neue Excel und musst die Daten in dein Arbeitsblatt hineinkopieren.
Durch den direkten Import in Excel kannst du z.B. die Überschriften weglassen um eigene Überschriften darüber zu setzen.
Der importierte Bereich erhält einen Namen "Abfrage n", auf den man z.B. in einem Chart bezugnehmen kann. Aktualisiere ich die Daten, verändert sich ggf. der Bereich, wird kürzer oder länger, und somit verändert sich auch das Chart.
Ich kann auch rechts neben den geladenen Daten bereits Formeln eintragen, die etwas damit rechnen.
Vorbereitet habe ich die Überschriften als Filter.

Man kann ebenso die Daten auch direkt in ein Chart oder eine Pivot laden.
Da gibts dann auf wiederum Exportmöglichkeiten in andere Arbeitsblätter von Teilen der geladenen Teile.
Ich kann berechnete Felder im Chart hinzufügen, die bei Aktualisierungen auch erhalten bleiben.

Alles das geht verloren, wenn ich die Daten immer erst aus einer anderen Excel importieren muss.
Dies könnte ich auch via ODBC oder externem Link. Macht die Sache aber nicht einfacher.

Wer dauernd empfielt, mach das doch mit SQL, kennt wohl Excel nicht gut genug um die Vorteile des Imports mit Aktualisierungsfunktion zu kennen.
Tut mir leid, wenn ich da jemanden mit auf die Füße trete, aber ich empfehle meinen Kunden immer den Import, was sich hinterher auch immer als die bessere Lösung bewiesen hat.

... komisch, dass ich da immer Gesichter von Menschen mit einem Excel Blatt vor mir stehen sehe, die mir erklären, dass die EDV falsch rechnet. Das mit der Neben - EDV ist (fast) überall schief gegangen, wo ich es gesehen habe.
Im übrigen kann man in Excel auch Tabellen verknüpfen und die Trennung von Eingabe- Rechen- und Ausgabefeldern ist auch in Excel dringend zu empfehlem.

D*B

[ILEMax]

@Baldur, #8

wir verwenden seit Jahren ein (kostenpflichtiges) Tool.
Damit können wir eine Vorlage verwenden, die z.b. Überschriften, Filter und Pivot-Funktionen hat.
Wir können an bestehende Excel anfügen, neue Tabellenblätter hinzufügen oder alles Überschreiben.

Die Geschäftsleitung, die morgens ihr Excel aufmacht, aktualisieren drückt und 10 Minuten Kaffee trinkt haben wir nicht. Auch wenn das ggf heute schneller geht, 'nicht funktionieren' durch Änderungen an der Version und/oder dem Treiber haben (ja, ist schon ein paar Tage her) uns damals zu der MIEXPORT+ Lösung gebracht.
Die Aufbereitungen laufen zu festen Zeiten und sind nicht vom Excel/LibreCalc/..., abhängig.

Besonders die Farbwechsel Formatierung ist sehr gut bei breiteren Tabellen.
Auch der horizontal / vertikal Wechsel ist schon was besonderes

[Fuerchau]

@Dieter
Ja, das ist bekannt. Ins besonders dann, wenn das kaufmännische Runden, das es auch in Excel gibt, vergessen wird.

@ILEMax
Du verwendest ja auch ein kostenpflichtiges Tool, dass sich viele eben sparen, da es ja Excel im Hause gibt. Man ist da dann immer wieder erstaunt, was man mit einer vernünftigen BI-Lösung noch alles zusätzlich herausholen kann.
Ich bin ja nur nicht dafür, mit SQL, egal ob Toolbox oder Script, sich einfache Excels zu erstellen, die nichts als Daten enthalten und bei den Usern jedesmal zu Mehrarbeiten führen.

Oft genug haben wir schon gehört, dass man keine Zeit für ein BI-System hätte, da die Controller mit ihren Excels den ganzen Monat für die Monatsauswertung benötigen.