TABEX/4 Newsletter 10 7/2013

TABEX/4 Newsletter 10 7/2013 Editorial Inhalt Sehr geehrte Damen und Herren! Editorial Migration von Tabellendaten zwischen relationalen Datenbanken Möglichkeiten der Exit-Programmierung Pflege von Tabellen aus relationalen Datenbanken Arten der Pflege von Tabellen aus relationalen Datenbanken Zeilenversionsführung TABEX Katalogtabelle (SQL Catalog) TABEX-Views SHS-Archivierung Wichtiger Hinweis: Problem mit IBM Java 1.7.0 build 2.6 Expertentipp 15 CSV-Import/Export BOI GmbH Impressum In diesem Newsletter behandeln wir vier Themen rund um TABEX/4: 1. Das erste Thema ist die Migration von Tabellendaten zwischen (unterschiedlichen) relationalen Datenbanken z.b. von DB2 nach Oracle oder von Informix nach DB2. 2. Zweitens zeigen wir die vielfältigen Möglichkeiten der Exit-Programmierung auf. 3. Der dritte Schwerpunkt beschreibt die unterschiedlichen Arten der Pflege von Tabellen aus relationalen Datenbanken. 4. Last but not least widmen wir uns der SHS- Archivierung. Unser aktueller Expertentipp beschreibt, wie numerische Tabellenfelder aus MS EXCEL beim CSV-Import mit führenden Nullen korrekt importiert werden können. Viel Spaß beim Lesen! Ihr BOI Team

1. Migration von Tabellendaten zwischen relationalen Datenbanken Sie haben Daten in einer relationalen Datenbank gespeichert, benötigen diese jedoch in einer anderen relationalen Datenbank auf einem anderen Betriebssystem? Sie möchten Daten von einer Datenbank in eine andere Datenbank migrieren und dabei Strukturanpassungen durchführen? TABEX/4 bietet Ihnen das Werkzeug, um Daten zwischen relationalen Datenbanken zu transportieren. Die Datenbanksysteme können dabei unterschiedlich sein. So können Sie z.b. Daten von Oracle in DB2 weiterverarbeiten od. Daten von Informix nach DB2 transportieren. Abb. Beispiel für eine Migration von Informix nach DB2 Mit Hilfe der Utilities TABN02 (Command SQLTAB) / TABN05 werden die Daten von der Quell- RDB (zum Beispiel Informix) in eine TABEX DB (im Beispiel TABEX_DB i ) zwischengespeichert. Da meistens Datentypanpassungen durchgeführt werden müssen, kann ein Anwenderprogramm zwischengeschaltet werden, welches die Datentypanpassungen durchführt und die Tabelle in eine zweite TABEX DB speichert (im Beispiel TABEX_DB d ). Mit dem Utility Command SQLUPD wird diese TABEX_DB d dann in die Zieldatenbank (im Beispiel DB2) eingespielt. Falls die Tabelle(n) in DB2 noch nicht existieren, können diese mit dem Utility TABN06 in der Zieldatenbank erstellt werden. Wenn Sie an weiteren Informationen zu dieser Funktionalität interessiert sind, wenden Sie sich bitte an unseren Support support@boi.at. 2. Möglichkeiten der Exit-Programmierung Exits sind SSL-Programme, die vom Kunden in TABEX/4 eingebunden werden können, um an gewünschter Stelle eigene Prüfungen, Nachbearbeitungen, usw. durchführen zu können. SSL, die TABEX-interne Programmiersprache, bietet auch die Möglichkeit, externe Programme (PL/I, Cobol usw.) aufzurufen. Neben den bekannten Exitmöglichkeiten wie z.b. Protokoll-Exits, Berechtigungsprüfungs-Exits oder Menü-Exits bietet TABEX/4 ein vielfältiges Spektrum an Erweiterungsmöglichkeiten. BOI - Newsletter 10 2 7 / 2013

2. Möglichkeiten der Exit-Programmierung An folgenden Stellen können im Ablauf des TABEX/4 Table Managers Exitprogramme des Kunden eingebunden werden: 1. Instanzinitialisierung (nach dem Laden der Instanzkonfigurationstabelle) 2. Setzen eines Wertes eines Systemparameters 3. nach Selektion eines Menüpunkts 4. Erzeugen eines TABEX View Statements für die dynamische Viewanzeige 5. Berechtigungsprüfung 6. Spezifizieren eines SSL-Programms als Handler für ein kundenspezifisches Icon 7. nach Selektion einer TABEX Tabelle aus dem TABEX Datenbankindex 8. Vorgabe für neues Tabellenversionsdatum 9. nach Commit eines Updates einer TABEX Tabelle 10. nach Online-Transfer von der Modifikationsdatenbank in die Produktionsdatenbank 11. Definieren von Sichten für das Laden von Daten von relationalen Datenbanken (mit technischen Feldern bei Zeilenversionsführung) 12. nach dem Laden von Daten aus relationalen Datenbanken 13. vor dem Update von Daten in relationale Datenbanken 14. Übertragen von Jobparameterwerten 15. Protokoll-Exits, wenn in der Web-Applikation die Protokollierung eingeschaltet ist, bzw für die Commands der Utilities TBVW01 und TBVW02. Protokoll-Exits können bei sämtlichen Tabellenänderungsmenüpunkten aufgerufen werden. (Die Namen der kundenspezifischen MOD-IDs müssen mit 'MY' beginnen.) 16. Ermitteln der TabellenID für den nächsten Step einer Tabellensequenz Für die Exit-Programmierung werden Interfacefunktionen zur Verfügung gestellt, die in der Implementierung der Exits verwendet werden können: 1. Abfragen der aktiven Instanz 2. Abfragen der aktiven Datenbank 3. Löschen des aktiven TABEX Tabellenindex, sodass das System diesen Index wieder erneut aufbauen muss 4. Lesen des Tabellenstatus 5. Schreiben von Kundendaten (10 Bytes) in den Tabellenstatus 6. Methoden zur Ausgabe von Textzeilen und Messages 7. Starten von Jobs 8. Lesen von Systemparameterwerten 9. Abfragen der Modul-Parameter 10. Aufbauen einer Verbindung zu einer relationalen Datenbank 11. Laden einer RDB-Tabelle als TABEX DB in den Speicher 12. Abfragen der MOD-ID 13. Abfragen von Tabellenberechtigungen 14. Abfragen von Freigabeverfahren Eine detaillierte Beschreibung aller Exitmöglichkeiten finden Sie in der BOIDOC_209a_config_en.pdf im Kapitel 'User Exits'. Wenn Sie Fragen zur Exitprogrammierung haben, wenden Sie sich bitte an unseren Support support@boi.at. Gerne unterstützen wir Sie im Rahmen eines Consultings bei der Implementierung Ihrer Exits. BOI - Newsletter 10 3 7 / 2013

3. Pflege von Tabellen aus relationalen Datenbanken Arten der Pflege von Tabellen aus relationalen Datenbanken Einzelsatz-Direktpflege über Zeilenselektion Einzelne Zeilen einer Tabelle werden selektiert und können parallel bearbeitet werden. Abb. Einzelsatz-Direktpflege Tabellen-Direktpflege Mehrere Zeilen einer Tabelle stehen auf dem Bildschirm für die Änderung zur Verfügung. Abb. Tabellen-Direktpflege Pflege mit Freigabeverfahren Bei der Pflege mit Freigabeverfahren, werden geänderte Daten in einer TABEX-Modifikationsdatenbank zwischengespeichert. Nach erfolgreicher Kontrolle werden die Änderungen zu einem festgelegten Zeitpunkt in der RDB nachgezogen, und aus der TABEX-Modifikationsdatenbank wieder gelöscht. Abb. Pflege mit Freigabeverfahren Pflege über SQLT-Tabellen mit/ohne Freigabeverfahren TABEX Tabellen mit SQL-Verbindung (sogenannte SQLT-Tabellen) werden via SQL SELECT Statement mit den Daten einer relationalen Datenbank verknüpft. Das Ergebnis des SELECT Statements wird dynamisch aus der relationalen Datenbank geladen, wenn die Tabelle aus der TABEX Datenbank geladen wird und dort keine Zeilen besitzt. Sowohl Table Manager als auch Utilities haben Funktionen zum Erzeugen und Updaten von SQLT-Tabellen. Abb. Pflege über SQLT-Tabellen mit/ohne Freigabeverfahren BOI - Newsletter 10 4 7 / 2013

3. Pflege von Tabellen aus relationalen Datenbanken Zeilenversionsführung Eine weitere Möglichkeit zur Pflege von Tabellen aus relationalen Datenbanken ist die Zeilenversionsführung. Um Daten zeitlich zu versionieren, und/oder die Änderungshistorie in einer RDB zu erhalten, besteht die Möglichkeit der sogenannten Zeilenversionsführung. Die dafür nötigen technischen Felder müssen in die Tabellenstruktur eingefügt werden. Die ursprüngliche Tabellenstruktur bzw. Sichten auf die Tabelle (z.b. die zum Tagesdatum gültigen Zeilen) werden über 'Views' abgebildet. Die Minimalvariante ist eine Versionierung ohne Änderungshistorie mit Gültig-Ab-Datum als letztes Schlüsselfeld, und Löschkennzeichen. Weitere Varianten mit Historisierung enthalten im Schlüssel zusätzlich ein Timestamp-Feld. Alternativ zum Löschkennzeichen kann auch ein Gültig-Bis-Datum verwendet werden. Der Vorteil dieser Speicherung ist, dass die gesamte Historie der Daten zentralisiert in einer RDB gespeichert ist und keine Hilfstabellen notwendig sind. Abb. Beispiel für Zeilenversionsführung BOI - Newsletter 10 5 7 / 2013

3. Pflege von Tabellen aus relationalen Datenbanken TABEX Katalogtabelle (SQL Catalog) Bei der Verwendung von relationalen Datenbanken besteht die Möglichkeit, innerhalb von TABEX/4 eine Katalogtabelle anstelle des internen Tabellenkatalogs der relationalen Datenbank zu verwenden. Zu diesem Zweck muss eine 'Katalog'-Tabelle in der relationalen Datenbank definiert werden. Vorteile der Verwendung des TABEX Katalogs sind: Es ist auf einfache Weise festzulegen, welche Tabellen der RDB für die Pflege mit TABEX vorgesehen sind. Ein Objektnamen kann explizit für Berechtigungen, Editor-Einstellungen,... zugewiesen werden. Es besteht die Möglichkeit, mehrere Kataloge in einer Datenbank für unterschiedliche Anwendungsfälle zu definieren. TABEX-Views Mit Hilfe von Views kann die Anzeige von TABEX-Tabellen und von relationalen Datenbank- Tabellen eingeschränkt werden. TABEX-Views erlauben Sichten auf Daten in TABEX-Datenbanken durch Angabe eines SELECT- Statements analog zu Views in relationalen Datenbanken. Über SQLT-Tabellen können auch Daten aus relationalen Datenbanken eingebunden werden. Soweit als möglich entsprechen die TABEX-SELECT-Statements in Syntax und Möglichkeiten den VIEW-SELECTs von relationalen Datenbanken. Beispiel: SELECT STAT_CODE,STAT_NAME,CONT_NAME FROM STATES LEFT JOIN CONTINENTS ON STATES.CONT_CODE=CONTINENTS.CONT_CODE WHERE CONT_CODE='E' Das Ändern von Tabellendaten über Views ist nicht möglich. 4. SHS-Archivierung Um die Anwendungsprogramme immer einen konsistenten Tabellenstand im SHS-Datenbereich verfügbar zu haben, erfolgt das Neuladen von SHS-Datenbereichen mit Hilfe eines Work- Datenbereiches. Nach erfolgreichem Laden der aktuellen Tabellen in den Work-Datenbereich wird dieser per Switch aktiviert. Nach dem Switch wird die SHS-Archivierung gestartet, in deren 1. Stufe ein Datenbereichs- Änderungsprotokoll gespeichert wird. Dieses enthält als Information, welche Änderungsaktion (Daten geändert, Definition geändert, Tabelle gelöscht,...) für welche Tabelle sich aus dem Neuladen ergeben hat. Mit der optionalen 2. Stufe werden alle geänderten und neu geladenen Tabellen in der Archivdatenbank gespeichert. Damit kann über die Auskunftsfunktionen der zu einem angegebenen Zeitpunkt aktive Stand von Tabellen abgefragt werden. BOI - Newsletter 10 6 7 / 2013

4. SHS-Archivierung Abb. SHS-Archivierung Wichtiger Hinweis: Problem mit IBM Java 1.7.0 build 2.6 Es wird DRINGEND EMPFOHLEN, für den Application-Server mit der TABEX-Web-Anwendung NICHT IBM Java 1.7.0 build 2.6 zu verwenden, da sonst nicht ausgeschlossen werden kann, dass fehlerhafte Daten gespeichert werden. Der Fehler liegt in der IBM Java-Implementierung der Methode setlength(int length) der Klasse StringBuffer: Wenn die neue Länge length größer ist als die Ausgangslänge des String- Objekts, dann sollten (auch gemäß IBM-javadoc) die restlichen Zeichen mit dem Character null (\u0000) gefüllt werden. Bei IBM Java 1.7.0 build 2.6 werden die restlichen Zeichen nicht mit null gefüllt, sondern mit irgendeinem Speicherinhalt. BOI - Newsletter 10 7 7 / 2013

Expertentipp 15 CSV-Import/Export Wenn Daten aus TABEX/4 exportiert - in MS EXCEL geändert - und wieder in TABEX/4 importiert werden, können Probleme mit Änderungen auftreten, die von MS EXCEL automatisch durchgeführt wurden (z.b. Entfernen führender Nullen). Ein Beispiel für eine Exportdatei: "PRODNR";"PRODNAME";"PRODGRP";"PRODPREIS" "000010";"Zange ";"Werkzeug ";"65" "000012";"Relay ";"Elektrik ";"52,12" "000013";"Saege ";"Werkzeug ";"89,99" "000045";"Welle ";"Mechanik ";"39,59" "000050";"Spray ";"Werkzeug ";"20,8" MS EXCEL entfernt diese Nullen beim Import in EXCEL. Wird nun in MS EXCEL wiederum eine CSV-Datei erzeugt, fehlen diese führenden Nullen. In unserem Beispiel wurde von EXCEL folgende Datei generiert: PRODNR;PRODNAME;PRODGRP;PRODPREIS 10;Zange ;Werkzeug ;65 12;Relay ;Elektrik ;52,12 13;Saege ;Werkzeug ;89,99 45;Welle ;Mechanik ;39,59 50;Spray ;Werkzeug ;20,8 Um diese Datei wieder korrekt in TABEX/4 importieren zu können, müssen die betreffenden Character-Felder in TABEX/4 mit dem Format Numeric (N) oder als Picture (PI) definiert werden. Dann ergänzt TABEX/4 beim Import wieder die führenden Nullen. Um fehlerhafte Daten vor dem Import in TABEX/4 zu erkennen, besteht die Möglichkeit, mit den in TABEX/4 zu importierenden Daten VOR dem Speichern einen Tabellenvergleich mit dem letzten in TABEX/4 gespeicherten Stand einen Tabellenvergleich durchzuführen. Dazu sind folgende Schritte nötig: Icon 'CSV-Import' drücken auf Icon 'mit anderer Tabelle vergleichen (Ctrl+D)' drücken, im folgenden Dialog 'Auswählen Datenbank für Vergleich' keine Datenbank auswählen, sondern nur auf das Icon 'auswählen (Alt+Ctrl+Shift+Right)' klicken (dadurch wird die aktuelle TABEX-Datenbank ausgewählt) und die Tabelle auswählen. Danach werden alle Änderungen in Form eines Differenz-Protokolls angezeigt. Mit dem Icon 'Vergleichtabellen ein-/ausblenden' können auch die Vergleichtabellen (vorherige und aktueller Stand) ausgeblendet werden. Dann wird das gesamte Differenz- Protokoll angezeigt. Sie finden unseren aktuellen Expertentipp auch im BOI Wiki: http://www2.boi.at/boiwiki/index.php/hauptseite BOI - Newsletter 10 8 7 / 2013

BOI GmbH Die BOI GmbH ist das führende Unternehmen für performantes, sicheres und komfortables Tabellenmanagement. Seit über 30 Jahren verbindet die BOI GmbH höchste Softwarequalität mit herausragendem Service. Namhafte TOP Unternehmen aus den Bereichen Versicherungen, Finanzdienstleistungen, Industrie und Dienstleistungen setzen seit vielen Jahren auf die Lösungen der BOI GmbH, wenn es um die Pflege sensibler Daten und andere Herausforderungen ihres Datenmanagements geht. Unser Leitprodukt TABEX/4 bietet zuverlässigen Tabellenzugriff mit höchster Performance schnell, sicher, problemlos ergonomische und einfach zu bedienende Tabellenverwaltung, die höchsten Sicherheitsansprüchen und Compliance-Erfordernissen entspricht: tausende Tabellen unterschiedlichster Größe pflegen einfach, fehlerfrei, komfortabel unbegrenzte Arbeit mit Tabellen über alle Plattformgrenzen hinweg und mit allen Datenbanken (copy&move). Für weitere Informationen können Sie sich gern jederzeit an uns wenden. Impressum BOI GmbH Spazgasse 4 A - 4040 Linz, Austria Telefon: +43 (0) 732 / 736423-0 Fax: +43 (0) 732 / 736423-2 Email: office@boi.at Web: http://www.boi.at Der Newsletter 11 wird Anfang Februar 2014 erscheinen. Als Kunde der BOI Software GmbH erhalten Sie den BOI - Newsletter an Ihre Email-Adresse zugesandt. Sie können den Newsletter auf unserer Website http://www.boi.at abonnieren oder als PDF- Dokument downloaden, und natürlich auch jederzeit wieder abbestellen. FN 81632y Landesgericht Linz UID: ATU24421409 BOI Linz, 2013 Wir freuen uns über Ihre Rückmeldungen! Redaktion: newsletter@boi.at Gabriele Kasper BOI - Newsletter 10 9 7 / 2013