tabex/4

TABEX/4
Newsletter 10
7/2013
Editorial
Inhalt
Sehr geehrte Damen und Herren!
Editorial
In diesem Newsletter behandeln wir vier
Themen rund um TABEX/4:
Migration von Tabellendaten zwischen
relationalen Datenbanken
Möglichkeiten der Exit-Programmierung
1. Das erste Thema ist die Migration von
Tabellendaten
zwischen
(unterschiedlichen) relationalen Datenbanken z.B. von
DB2 nach Oracle oder von Informix nach DB2.
Pflege von Tabellen aus relationalen
Datenbanken
2. Zweitens zeigen wir die vielfältigen
Möglichkeiten der Exit-Programmierung auf.
•
•
•
•
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
3. Der dritte Schwerpunkt beschreibt die
unterschiedlichen Arten der Pflege von
Tabellen aus relationalen Datenbanken.
4. Last but not least widmen wir uns der SHSArchivierung.
Unser aktueller Expertentipp beschreibt, wie
numerische Tabellenfelder aus MS EXCEL
beim CSV-Import mit führenden Nullen korrekt
importiert werden können.
Expertentipp 15 – CSV-Import/Export
Viel Spaß beim Lesen!
BOI GmbH
Impressum
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 QuellRDB (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_DBd 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 [email protected].
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
[email protected]. 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 DatenbankTabellen eingeschränkt werden.
TABEX-Views erlauben Sichten auf Daten in TABEX-Datenbanken durch Angabe eines SELECTStatements 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 WorkDatenbereiches. 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 StringObjekts, 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
"000012";"Relay
";"Elektrik
"000013";"Saege
";"Werkzeug
"000045";"Welle
";"Mechanik
"000050";"Spray
";"Werkzeug
";"65"
";"52,12"
";"89,99"
";"39,59"
";"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
12;Relay
;Elektrik
13;Saege
;Werkzeug
45;Welle
;Mechanik
50;Spray
;Werkzeug
;65
;52,12
;89,99
;39,59
;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 DifferenzProtokoll 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
Der Newsletter 11 wird Anfang Februar 2014
erscheinen.
Spazgasse 4
Als Kunde der BOI Software GmbH erhalten Sie
den BOI - Newsletter an Ihre Email-Adresse
zugesandt.
A - 4040 Linz, Austria
Telefon: +43 (0) 732 / 736423 - 0
Fax:
+43 (0) 732 / 736423 - 2
Sie können den Newsletter auf unserer Website
http://www.boi.at abonnieren oder als PDFDokument downloaden, und natürlich auch
jederzeit wieder abbestellen.
Email: [email protected]
Web:
http://www.boi.at
FN 81632y Landesgericht Linz
Wir freuen uns über Ihre Rückmeldungen!
UID: ATU24421409
Redaktion: [email protected]
© BOI Linz, 2013
BOI - Newsletter 10
Gabriele Kasper
9
7 / 2013