deren Funktionsweise zu kennen. Häufig ist eine Kombination von mehreren Werkzeugen notwendig.

Voraussetzung für das Arbeiten mit Datenbanken ist ein Grundverständnis für den Aufbau einer Datenbank im ERP-System.

1                     Zielgruppe

Administratoren

2                     Begriffsbestimmung

Datenbank

Eine von einem Datenbank-Management-System (DBMS) verwaltete Datenbank ist eine Ausprägung eines Datenbankschemas. Eine Datenbank umfasst die Daten, die gemäß eines zugehörigen Datenbankschemas strukturiert sind. In der Systemkonfiguration umfasst eine Datenbank die Verwaltungs- und Zugriffsinformationen für eine Datenbank in einem Datenbanksystem.

Datenbankschema

Das Datenbankschema enthält die Strukturinformation der Objekte, die in einer Datenbank gespeichert werden können.

Tabellenbeschreibung

Die Tabellenbeschreibung dient als Vorlage für die Tabellendefinition und die Tabelle. Jedes Business Object besitzt eine Tabellenbeschreibung. Aus der Tabellenbeschreibung kann das Schema der Tabelle abgeleitet werden, in der die Business-Object-Instanzen gespeichert werden. Die Tabellenbeschreibung wird aus der Objektbeschreibung generiert.

Tabellendefinition

Eine Tabellendefinition beschreibt das Schema einer Tabelle. Die Tabellendefinition enthält eine datenbankunabhängige Beschreibung der Spalten und Indizes einer Tabelle.

3                     Vorgehensweisen

Im normalen Betrieb des ERP-Systems sind manuelle Reorganisationen oder Reparaturen auf einer Datenbank nicht notwendig.

Bei Änderungen bei den für lokalisierbare Attribute verfügbaren Sprachen oder bei der Wiederherstellung einer Datenbank aus einer Sicherung ist notwendig, die Datenbank zu reorganisieren. Der Ablauf von Änderungen ist meist der folgende:

Grundlegender Ablauf für Datenbankänderungen

Besonders wichtig ist, dass vor jeder Änderung eine vollständige Sicherung des Systems vorliegt und dass diese jederzeit und kurzfristig zurückgesichert werden kann. Wenn Änderungsoperationen an Datenbanken auf einem System durchgeführt werden, dann sollten keine anderen Benutzer auf dem System arbeiten. Ansonsten kann die Datenbank in inkonsistente Zustände kommen oder die Arbeit der angemeldeten Benutzer geht verloren. Nach der Durchführung der Änderung sollte die Konsistenz des Systems geprüft werden. Nur wenn die Änderung fehlerfrei durchgeführt werden konnten und keine Daten verloren gegangen sind, darf das System wieder zur Benutzung freigegeben werden.

Eine Datenbank kann aufgrund der folgenden Möglichkeiten inkonsistent werden:

• Fehlerhafte Administration
• Fehlbedienungen bei der Softwareentwicklung
• Fehlerhafte Datenbankänderungen
• Fehler im ERP-System

Unabhängig davon, ob eine Datenbank reorganisiert oder ob ein Fehler repariert werden soll, ist der grundlegende Ablauf immer identisch:

Grundlegender Ablauf bei Datenbankfehler

Wenn ein Fehler beim Zugriff auf eine Datenbank beobachtet wird, dann sollten Sie als erstes soweit möglich den Umfang und die Art des Fehlers einordnen. Wenn Sie den Fehler nicht beheben können, dann nehmen Sie Verbindung mit dem Supportcenter auf. Wenn Sie den Fehler selbst beheben können, dann erstellen Sie zunächst eine vollständige Sicherung des Systems. Führen Sie die Fehlerkorrektur durch und kontrollieren Sie, ob der Fehler tatsächlich behoben ist und keine weiteren Daten verloren gegangen sind. Wenn Sie während der Fehlerkorrektur bemerken, dass das Ihre Möglichkeiten übersteigt, dann sichern Sie das System zurück und kontaktieren Sie das Supportcenter.

3.1               Änderungen

3.1.1          Anzeigesprache hinzufügen

Alle Sprachen in der Repository-Datenbank können als Anzeigesprachen verwendet werden.

Wenn Sie eine neue Anzeigesprache hinzufügen möchten, dann sollten Sie die aktuellste Sprachaktualisierung für diese Sprache installieren. Im Kapitel „Sprachauslieferung installieren“ wird dieser Vorgang beschrieben.

Wenn keine Sprachaktualisierung für diese Sprache vorliegt, dann müssen Sie alle Übersetzungen selbst erstellen. Gehen Sie dazu wie im Kapitel „Nebensprachen ändern“ beschrieben vor.

3.1.2          Sprachauslieferung installieren

Installieren Sie eine Sprachauslieferung wie folgt:

1. Legen Sie die Sprachaktualisierung im Semiramis-Verzeichnis unter refreshes/import
2. Starten Sie die Installation der Sprachaktualisierung für die Sprache XY

inslng -language:XY

Das Tool inslng erweitert die Konfiguration und die Datenbankinformationen automatisch um eine neue Nebensprache, wenn die zu installierende Sprache für diese Datenbank noch nicht konfiguriert ist. Weitere Reorganisationen sind nicht notwendig.

3.1.3          Anzeigesprache löschen

Wenn Sie eine Anzeigesprache löschen möchten, dann gehen Sie wie im Kapitel „Nebensprachen ändern“ beschrieben vor.

3.1.4          Nebensprachen ändern

Wenn Sie eine neue Nebensprache auf einer Datenbank hinzufügen oder eine existierende Nebensprache auf einer Datenbank löschen möchten, dann gehen Sie wie folgt vor:

1. Erstellen Sie eine Sicherung des Systems.
2. Öffnen Sie die Anwendung „Systemcockpit“.
3. Öffnen Sie die Datenbank, die Sie ändern möchten.
4. Ändern Sie die Nebensprachen der Datenbank.
5. Speichern Sie die Datenbank.
6. Wechseln Sie zu der Toolshell eines ERP-System-Application-Servers des Systems, zu dem die Datenbank gehört.
7. Erzeugen Sie die Datenbankinformationen für diese Datenbank neu.

crtdbinf -db:XY -nlsAutomatic

Im Kapitel „Datenbankinformationen erzeugen“ wird dieser Vorgang beschrieben.

8. Prüfen Sie, ob die lokalisierbaren Attribute die von Ihnen erwarteten Werte haben.

Wenn Sie eine neue Nebensprache hinzufügen, dann werden für diese Sprache für jedes lokalisierbare Attribut Übersetzungen erzeugt. Diese Übersetzungen werden mit dem Text in der Primärsprache der Datenbank initialisiert.

Beispiel:

Bei einer Datenbank mit der Primärsprache „de“ und der Nebensprache „en“ wird die Nebensprache „it“ hinzugefügt. Die Werte eines lokalisierbaren Attributs ändern sich dadurch beispielsweise wie folgt:

de=Haus, en=house -> de=Haus, en=house, it=Haus

Wenn Sie eine Nebensprache löschen, dann werden auch alle Übersetzungen in dieser Sprache unwiederbringlich gelöscht.

Wenn Sie die Nebensprachen der Repository-Datenbank geändert haben, so müssen Sie auch die Nebensprachen der OLTP-Datenbanken ändern, da die Nebensprachen der Repository-Datenbank auch auf den OLTP-Datenbanken verwendet werden.

3.1.5          Primärsprache und Nebensprache tauschen

Wenn Sie eine Nebensprache als Primärsprache einer Datenbank festlegen möchten, dann müssen Sie wie folgt vorgehen:

1. Erstellen Sie eine Sicherung des Systems.
2. Wechseln Sie zu der Toolshell eines ERP-System-Applications-Servers des Systems, zu dem die Datenbank gehört.
3. Tauschen Sie die alte Primärsprache gegen die neue Primärsprache LANG.

Hinweis:

Den Befehl zum Austauschen der Primärsprache dürfen Sie nur einmal ausführen. Ein mehrfacher Aufruf führt zu Fehlern.

rgzdbt -exchangeContentLanguage:LANG -modify -db:XY -all

Ersetzen Sie die Zeichenkette „LANG“ durch die neue Primärsprache (z. B. „de“).

Nach dem Austausch ist die alte Primärsprache als Nebensprache in den NLS-Tabellen enthalten. Die Übersetzungen in der neuen Primärsprache wurden aus den NLS-Tabellen gelöscht und in das Hauptobjekt übernommen.

4. Öffnen Sie die Anwendung „Systemcockpit“.
5. Öffnen Sie die Datenbank, die Sie ändern möchten.
6. Ändern Sie die Primärsprache der Datenbank.
7. Entfernen Sie die neue Primärsprache aus den Nebensprachen der Datenbank.
8. Fügen Sie die alte Primärsprache zu den Nebensprachen der Datenbank hinzu.
9. Speichern Sie die Datenbank.
10. Wechseln Sie zu der Toolshell eines ERP-System-Application-Servers des Systems, zu dem die Datenbank gehört.
11. Erzeugen Sie die Datenbankinformationen für diese Datenbank neu.

crtdbinf -db:XY -nlsManual

Im Kapitel „Datenbankinformationen erzeugen“ wird dieser Vorgang beschrieben.

12. Prüfen Sie, ob die lokalisierbaren Attribute die von Ihnen erwarteten Werte haben.

3.1.6          Datenbank kopieren

Eine Datenbank kopieren Sie mit den ERP-System-Tools, wenn Sie die Datenbank auf ein anderes Datenbank-Management-System (DBMS) kopieren möchten. Das Kopieren der Datenbank mit DBMS-Mitteln ist beim Kopieren einer Datenbank auf dem gleichen DBMS deutlich performanter. Weitere Informationen finden Sie im Kapitel „Datenbank mit DBMS-Mitteln kopieren“.

Beim Kopieren einer Datenbank „SDB“ aus dem System „SSYS“ in eine Datenbank „TDB“ aus dem System „TSYS“ gehen Sie wie folgt vor:

1. Legen Sie eine neue Datenbank im DBMS des Zielsystems an.
2. Erstellen bzw. ändern Sie ggf. die Konfiguration der Datenbank „TDB“ im Systemcockpit.

Primärsprache der Quell- und Zieldatenbank müssen identisch sein. Jede Nebensprache der Zieldatenbank muss auch auf der Quelldatenbank definiert sein. Erst nach dem Kopieren können Sie die Primärsprache ändern oder neue Nebensprachen hinzufügen.

3. Wechseln Sie auf eine Toolshell eines ERP-System-Application-Servers des System „SSYS“.
4. Erstellen Sie das Datenbankschema der Datenbank „TDB“:

crtdbt -db:TSYS.TDB

5. Kopieren Sie die Daten aus der Datenbank „SDB“ in die Datenbank „TDB“.

cpydbt -src:SDB -dst:TSYS.TDB

Beim Kopieren mit dem Tool cpydbt werden nur die aktiven Tabellen kopiert. Wenn Sie Kopien innerhalb eines Systems erzeugen, achten Sie darauf, dass Sie die temporären Tabellen mit dem Tool crtbo erneut erzeugen müssen.

6. Prüfen Sie, ob die Datenbank zu dem im System „TSYS“ aktiven Datenbankschema passt:

chkdbt -table:% -db:TDB

Im Kapitel „Version der Datenbanktabellen prüfen“ wird dieser Vorgang beschrieben.

Bei systemübergreifenden Kopien kann vorkommen, dass die Kopie eine Version einer Datenbanktabelle enthält, die das Zielsystem nicht kennt. In diesem Fall kann die Kopie nicht verwendet werden.

7. Ändern Sie ggf. die Haupt- und Nebensprachen der Datenbank. Beachten Sie dazu die Kapitel „Nebensprachen ändern“ und „Primärsprache und Nebensprache tauschen“.

Beachten Sie die im Kapitel „Allgemeine Anmerkungen zum Kopieren von Datenbanken“ aufgeführten Anmerkungen.

3.1.7          Datenbank mit DBMS-Mitteln kopieren

Das Kopieren der Datenbank mit DBMS-Mitteln ist beim Kopieren einer Datenbank auf dem gleichen DBMS die schnellste Möglichkeit, eine Datenbank zu kopieren.

Beim Kopieren einer Datenbank „SDB“ aus dem System „SSYS“ in eine Datenbank „TDB“ aus dem System „TSYS“ gehen Sie wie folgt vor:

1. Erstellen bzw. ändern Sie ggf. die Konfiguration der Datenbank „TDB“ im Systemcockpit.

Haupt- und Nebensprachen der Quell- und Zieldatenbank müssen identisch sein. Erst nach dem Kopieren können Sie die Primärsprache und Nebensprachen ändern.

2. Erstellen Sie die Kopie der Datenbank mithilfe des DBMS.

Beim Kopieren mit DBMS-Mitteln werden sowohl die aktiven als auch die temporären Tabellen kopiert. Bei Kopien aus einem Entwicklungssystem sollten Sie daher sicherstellen, dass keine Business Objects in Bearbeitung sind.

3. Wechseln Sie auf eine Toolshell eines ERP-System-Application-Servers des System „TSYS“.
4. Erzeugen Sie die Datenbankinformationen für die Datenbank „TDB“:

crtdbinf -db:TDB -nlsAutomatic

Im Kapitel „Datenbankinformationen erzeugen“ wird dieser Vorgang beschrieben.

5. Prüfen Sie, ob die Datenbank zu dem im System „TSYS“ aktiven Datenbankschema passt:

chkdbt -table:% -db:TDB

Im Kapitel „Version der Datenbanktabellen prüfen“ wird dieser Vorgang beschrieben.

Bei systemübergreifenden Kopien kann vorkommen, dass die Kopie eine Version einer Datenbanktabelle enthält, die das Zielsystem nicht kennt. In diesem Fall kann die Kopie nicht verwendet werden.

Beachten Sie die im Kapitel „Allgemeine Anmerkungen zum Kopieren von Datenbanken“ aufgeführten Anmerkungen.

3.1.8          Allgemeine Anmerkungen zum Kopieren von Datenbanken

Systemübergreifende Datenbankkopien sind nur dann problemlos, wenn im Quell- und Zielsystem die identischen Softwareaktualisierungen installiert wurden. Daher ist meist nicht möglich, eine Datenbank zwischen Systemen unterschiedlicher Kunden auszutauschen. Release-übergreifende Kopien sind prinzipiell nicht möglich.

Die folgende Tabelle beschreibt, zwischen welchen Systemen Datenbankkopien prinzipiell möglich sind.

	Nach DV	Nach DT	Nach T	Nach P
Von DV	möglich	Konflikt	Konflikt	Konflikt
Von DT	Upgrade	möglich	Konflikt	Konflikt
Von T	Upgrade	Upgrade	möglich	Konflikt
Von P	Upgrade	Upgrade	Upgrade	möglich

Erläuterung der Tabelle:

• möglich

Das Datenbankschema ist innerhalb eines Systems identisch.

• Upgrade

Das Datenbankschema der Kopie kann veraltet sein und muss geprüft und ggf. reorganisiert werden.

• Konflikt

Das Datenbankschema der Kopie kann aktueller sein als das Datenbankschema des Zielsystems und muss geprüft und kann ggf. nicht verwendet werden.

• DV = Entwicklungssystem
• DT = Entwicklungstestsystem
• T = Testsystem
• P = Produktivsystem

Selbst wenn das Kopieren von Datenbanken bezüglich des Datenbankschemas her möglich ist, müssen Sie jedoch die folgenden Einschränkungen beachten:

• Beachten Sie, dass die OLAP-Datenbank aggregierte Informationen aus der OLTP-Datenbank enthält. Wenn Sie eine OLTP-Datenbank kopieren, ohne die zugehörige OLAP-Datenbank im Zielsystem zu reorganisieren, dann wird die OLAP-Datenbank falsche Daten enthalten.
• Wurden spezielle Arbeitsbereiche auf einer Datenbank erstellt, dann können Sie auf die Inhalte dieser Arbeitsbereiche im Zielsystem nicht zugreifen.

Sinnvolle Anwendungsfälle für Datenbankkopien sind beispielsweise Folgende:

• Übernahme der OLTP- und OLAP-Datenbank aus dem Produktivsystem in das Kundenadaptierungstest- oder Kundenadaptierungssystem, um Kundenfehlermeldungen nachzuvollziehen.
• Übernahme der OLTP- und OLAP-Datenbank aus dem Produktivsystem in das Kundentestsystem, um Softwareaktualisierungen mit den aktuellen Kundendaten zu testen.
• Datenbank wiederherstellen.

3.1.9          Datenbanktabellen löschen

Vor dem Löschen von Datenbanktabellen auf einer Datenbank legen Sie eine vollständige Sicherung des Systems an. Wenn Business Objects innerhalb eines Releases gelöscht werden, dann müssen die zugehörigen Datenbanktabellen explizit gelöscht werden. Die Datenbanktabellen werden nicht automatisch gelöscht, wenn eine Softwareaktualisierung mit einer Löschung auf dem System installiert oder wenn die Entwicklungsaufgabe mit der Löschung aktiviert wird. Im Kapitel „Datenbanktabellen analysieren“ wird beschrieben, wie Sie die überflüssigen Datenbanktabellen finden. Bevor Sie Datenbanktabellen löschen stellen Sie auf Entwicklungssystemen sicher, dass die zugehörigen Business Objects nicht in Entwicklungsaufgaben enthalten sind. Mit dem folgenden Befehl löschen Sie die Tabelle „XY“ auf der Datenbank „DX“:

dltdbt -table:XY -db:DX

3.1.10       Datenbankinformationen erzeugen

Sie können die Datenbankinformationen mit dem folgenden Befehl aus der Konfiguration der Datenbank erzeugen:

crtdbinf -db:DX

Beachten Sie, dass bei Änderungen der Haupt- oder Nebensprachen zusätzliche Reorganisationsschritte erforderlich sind. Mit der Option „-nlsAutomatic“ können Sie die Nebensprachen einer Datenbank automatisch reorganisieren. Mit der Option „-nlsManual“ müssen Sie die Reorganisation der Nebensprachen manuell durchführen. Die Hauptsprache einer Datenbank kann nicht automatisch geändert werden. Weitere Informationen zum Ändern der Primärsprache einer Datenbank finden Sie im Kapitel „Primärsprache und Nebensprache tauschen“.

Die Nebensprachen der Repository-Datenbank werden auch auf den OLTP-Datenbanken gespeichert. Wenn Sie die Nebensprache der Repository-Datenbank verändern, dann müssen Sie auch die Datenbankinformationen aller OLTP-Datenbanken neu erzeugen.

3.2               Fehlermeldungen

3.2.1          Ausnahme: Object is marked to Delete

Wenn innerhalb einer Anwendung auf ein Business Object zugegriffen wird, das ein Löschkennzeichen hat, dann erscheint die folgende Fehlermeldung (Ausnahme):

Exception: Object mapper could not be created! Object is marked to delete!

Diese Meldung weist auf einen Programmierfehler hin, da als gelöscht gekennzeichnete Objekte nicht mehr verwendet werden dürfen. Eliminieren Sie die Verwendung des Objekts oder entfernen Sie die Löschkennzeichnung.

Mithilfe der Option -useDeletedTables können Sie beim Start des ERP-System-Application-Servers diese Prüfung deaktivieren. Die Deaktivierung der Prüfung löst das Problem nicht und kann unter Umständen zu inkonsistenten Zuständen führen.

3.2.2          Konsole: ERROR Mapper … is generated for Version …

Wenn die Version des Mappers weder zu der Version der aktiven noch der temporären Tabelle auf einer Datenbank passt, dann wird die folgende Meldung auf die Konsole ausgegeben:

ERROR: Mapper XY is generated for Version X but active version is Y and locked version is Z

Diese Meldung deutet darauf hin, dass die Java-Klassen der Mapper nicht zu den auf der Datenbank generierten Tabellen passen. Das kann mehrere Ursachen haben:

• Der ERP-System-Application-Server (SAS) hat keinen Zugriff auf die aktuellen Klassen.
• SAS nach Datenmodelländerung nicht neu gestartet.
• Der Klassenpfad des SAS ist falsch.
• Die Tabelle wurde nach Versionsänderung nicht generiert.
• Die Datenbank ist nicht mit allen SAS im System verbunden.
• Ein älterer Stand der Datenbank wurde zurückgesichert.
• Die Datenbank passt nicht zu dem aktuellen System.

Als erstes stellen Sie sicher, dass der ERP-System-Application-Server Zugriff auf die aktuellsten Klassen hat. Wenn das Problem auch nach einem Neustart mit dem korrekten Klassenpfad weiter besteht, dann gehen Sie weiter vor wie im Kapitel „Version der Datenbanktabellen prüfen“ beschrieben ist.

3.2.3          Konsole: ERROR TableDefinition for class … not found …

Wenn eine Tabelle auf einer Datenbank nicht generiert wurde, dann wird auch keine Tabellendefinition auf dieser Datenbank erzeugt.

ERROR: TableDefinition for class XY not found in database Z

Der ERP-System-Application-Server (SAS) greift auf eine Tabelle zu, die auf dieser Datenbank nicht existiert. Das kann die folgenden Ursachen haben:

• Der SAS hat keinen Zugriff auf die aktuellen Klassen.
• SAS nach Datenmodelländerung nicht neu gestartet.
• Der Klassenpfad des SAS ist falsch.
• Der Zugriff auf die Tabelle ist ein Programmierfehler.
• Die Tabelle wurde nicht generiert.

Als erstes stellen Sie sicher, dass der ERP-System-Application-Server Zugriff auf die aktuellsten Klassen hat. Wenn das Problem auch nach einem Neustart mit dem korrekten Klassenpfad weiter besteht, dann öffnen Sie die Objektbeschreibung des Business Objects in der Anwendung „Entwicklungsobjekte“. Sie können mit den „Datenbank- und Cache-Einstellungen“ (Karteireiter „Editor“, Unterkarteireiter „Einstellungen“) kontrollieren, ob das Objekt auf der angegebenen Datenbank generiert sein sollte. Wenn das Objekt nach der Objektbeschreibung auf dieser Datenbank nicht generiert werden soll, dann handelt es sich um einen Programmierfehler.

Wenn die Tabelle eigentlich auf der Datenbank existieren sollte, dann müssen Sie den Grund für diese Inkonsistenz finden. Mögliche Ursachen sind:

• Ein älterer Stand der Datenbank wurde zurückgesichert.
• Die Datenbank war nicht verbunden als Softwareaktualisierungen installiert wurden
• Die Datenbank war nicht verbunden als Datenmodelländerungen vorgenommen wurden.

Bei all diesen Ursachen können auch weitere Tabellen von dem Problem betroffen sein. Verfahren Sie wie im Kapitel „Version der Datenbanktabellen prüfen“ beschrieben ist, um die Versionen aller existierenden Tabellen zu prüfen.

Erzeugen Sie die fehlenden Tabellen wie im Kapitel „Business Object reorganisieren“ beschrieben ist. Führen Sie falls vorhanden Datenaktualisierungen aus, um die neuen Tabellen zu initialisieren.

3.2.4          Konsole: INFORMATION: Mapper XY uses table X on database Y

Immer wenn ein Mapper das erste Mal auf die temporäre Tabelle zugreift, dann wird abhängig davon, ob der ERP-System-Application-Server (SAS) mit der Option ‑writeConvertedTables gestartet wurde, eine der folgenden Meldungen ausgegeben:

INFORMATION: Mapper XY uses table X on database Y in read only mode.

INFORMATION: Mapper XY uses table X on database Y in read/write mode.

Die Meldung bedeutet, dass die Version des Mappers nicht zu der Version der aktiven Tabelle passt, sondern zu der Version der temporären Tabelle. Das kann die folgenden Ursachen haben:

• Das betroffene Business Object ist in Bearbeitung.
• Der SAS hat keinen Zugriff auf die aktuellen Klassen.
• SAS nach Datenmodelländerung nicht neu gestartet.
• Der Klassenpfad des SAS ist falsch.
• Eine Softwareaktualisierung wurde installiert aber noch nicht vollständig aktiviert.

Als erstes sollten Sie prüfen, ob das Objekt gerade in Bearbeitung ist, oder ob Sie gerade eine Softwareaktualisierung installieren. Wenn das der Fall ist, dann wird die Meldung nach Abschluss der Bearbeitung bzw. des Installierens nicht mehr erscheinen. Ansonsten sollten Sie den Klassenpfad prüfen und den betroffenen SAS neu starten.

3.2.5          Ausnahme: Mapper is read only: active table got invalid version!

Wenn eine temporäre Tabelle verwendet wird und diese nicht explizit mit der Option -writeConvertedTables zum Schreiben freigegeben wurde, dann wird bei jedem Schreibzugriff die folgende Meldung ausgegeben:

Exception: Mapper is read only: active table got invalid version!

Wenn Sie in die temporäre Tabelle schreiben möchten, dann starten Sie den ERP-System-Application-Server (SAS) mit -writeConvertedTables. Beachten Sie jedoch, dass Schreiboperationen in die temporären Tabellen aufgrund des meist komplexen Datenmodells zu Inkonsistenzen auf der Datenbank führen können. Ansonsten gehen Sie vor wie im Kapitel „Konsole: INFORMATION: Mapper XY uses table X on database Y“ beschrieben ist.

3.2.6          Ausnahme: Error while selecting in mapper

Wenn beim Lesen eines Business Objects auf einer Datenbank ein Fehler auftritt, dann wird die folgende Meldung ausgegeben:

Exception: Error while selecting in mapper XY

Datenbankfehler beim Lesen von Business Objects können unterschiedliche Ursachen haben:

• Der ERP-System-Application-Server (SAS) hat keinen Zugriff auf die aktuellen Klassen.
• SAS nach Datenmodelländerung nicht neu gestartet.
• Der Klassenpfad des SAS ist falsch.
• Das Datenbanksystem hat einen Fehler.
• Die Datenbanktabelle passt nicht zu dem Mapper.

Als erstes stellen Sie sicher, dass der ERP-System-Application-Server Zugriff auf die aktuellsten Klassen hat. Wenn das Problem auch nach einem Neustart mit dem korrekten Klassenpfad weiter besteht, dann prüfen Sie, ob der Zugriff auf die Datenbank möglich ist.

Besteht der Fehler weiterhin, dann verfahren Sie wie im Kapitel „Version der Datenbanktabellen prüfen“ beschrieben ist, um die Versionen aller existierenden Tabellen zu prüfen. Wenn diese Prüfung keinen Fehler meldet, dann verfahren Sie wie im Kapitel „Datenbanktabellen analysieren“ beschrieben ist, um die Datenbanktabellen mit der Tabellendefinition zu vergleichen.

3.2.7          Konsole: Invalid database languages found …

Beim Start des ERP-System-Application-Servers (SAS) wird bei allen verbundenen Datenbanken geprüft, ob die in der Konfiguration gespeicherten Nebensprachen mit den auf der Datenbank verwendeten Nebensprachen übereinstimmen. Bei Abweichungen wird die folgende Meldung auf der Konsole ausgegeben:

Error     : Invalid database languages found in database XY

Diese Meldung kann die folgenden Ursachen haben:

• Die Nebensprachen der Datenbank wurden in der Konfiguration verändert.
• Die Datenbank wurde aus einer Sicherung wiederherstellt.

Wie im Kapitel „Datenbankinformationen ausgeben“ beschrieben, können Sie die auf der Datenbank gespeicherten Nebensprachen abfragen. Diese müssen Sie mit den Nebensprachen der Konfiguration abgleichen. Wenn Sie Nebensprachen hinzufügen oder entfernen möchten, dann gehen Sie vor wie im Kapitel „Nebensprachen ändern“ beschrieben ist.

3.2.8          Konsole: Invalid content language found …

Beim Start des ERP-System-Application-Servers (SAS) wird bei allen verbundenen Datenbanken geprüft, ob die in der Konfiguration gespeicherte Primärsprache mit der auf der Datenbank verwendeten Primärsprache übereinstimmt. Bei Abweichungen wird die folgende Meldung auf der Konsole ausgegeben:

Error     : Invalid content language found in database XY

Diese Meldung kann die folgenden Ursachen haben:

• Die Primärsprache der Datenbank wurde in der Konfiguration verändert.
• Die Datenbank wurde aus einer Sicherung wiederherstellt.

Wie im Kapitel „Datenbankinformationen ausgeben“ beschrieben, können Sie die auf der Datenbank gespeicherte Primärsprache ausgeben. Diese müssen Sie mit der Primärsprache der Konfiguration abgleichen. Wenn Sie Primärsprachen ändern möchten, dann gehen Sie vor wie im Kapitel „Primärsprache und Nebensprache tauschen“ beschrieben.

3.2.9          Konsole: Database information not found …

Beim Start des ERP-System-Application-Server (SAS) wird bei allen verbundenen Datenbanken geprüft, ob Datenbankinformationen zu der in der Konfiguration eingestellten Datenbank in der Datenbank existieren. Wenn zu der konfigurierten Datenbank keine Datenbankinformationen auf der Datenbank gespeichert sind, dann wird die folgende Meldung auf der Konsole ausgegeben, wenn auf eine Datenbank aus einem anderen System zugegriffen wird.

Error     : Database information not found in database XY

Das kann beispielsweise durch einen Fehler in der Konfiguration passieren oder dadurch, dass die Datenbank mit Mitteln des DBMS kopiert wurde. Für diesen Fall finden Sie im Kapitel „Datenbank mit DBMS-Mitteln kopieren“ weitere Informationen.

3.3               Fehleranalyse – Konsistenzprüfungen

Bevor irgendwelche Reparaturmaßnahmen durchgeführt werden, sollten Sie zunächst die Ursache und den Umfang des Fehlers analysieren.

3.3.1          Version der Datenbanktabellen prüfen

Mit dem Tool chkdbt können Sie die Version der Tabellenbeschreibung mit der aktiven Version der Tabellendefinition vergleichen. Auf Entwicklungssystemen können die Versionen abweichen, wenn die Business Objects in einer Entwicklungsaufgabe enthalten sind. In einem Test- oder Produktivsystem dürfen keine Abweichungen zwischen der Tabellenbeschreibung und der Tabellendefinition vorkommen.

Die Version der Datenbanktabellen können Sie mit dem folgenden Befehl für alle Tabellen der Datenbank „DX“ prüfen:

chkdbt -table:% -db:DX

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen prüfen (chkdbt)“ zu dem Tool chkdbt. Das Tool gibt alle auf dieser Datenbank generierten Business Objects mit der Information aus, ob deren aktive Version der Tabellendefinition zu der Version der Tabellenbeschreibung passt:

Database DX initialised

 

Database: DX

=============================================

compare version

=============================================

 

XA repository version VRA database version active VAA locked VLA

XB repository version VRB database version active VAB

Wenn zu einem Business Object die temporäre Tabelle erzeugt wurde, dann wird auch die Version der temporären Tabelle ausgegeben (siehe VLA). Auf einem Entwicklungssystem ist dies ein normaler Zustand, wenn das Business Object in einer Entwicklungsaufgabe ist und generiert wurde. Auf Test- und Produktivsystemen sollten keine temporären Tabellen existieren.

Version der Datenbanktabellen prüfen

Wenn eine der Versionsnummern „null“ ist, dann hat die Tabellenbeschreibung eine Version, die das Repository nicht kennt. Wenn die Tabellendefinition eine Version enthält, die dem Repository unbekannt ist, dann darf die Datenbank nicht in diesem System verwendet werden. Im Allgemeinen können unbekannte Versionen jedoch nur dadurch entstehen, dass eine Datenbank mit Datenbankmitteln kopiert wird bzw. zeitweilig nicht mit dem System verbunden ist.

Wenn beim Installieren von Softwareaktualisierungen ein Fehler auftritt und dieser zu einer Abweichung der Versionen der Tabellenbeschreibung und der Tabellendefinition führt, dann empfiehlt sich die Wiederherstellung des Systems aus der Sicherung vor dem Installieren der Softwareaktualisierungen. Bevor die Softwareaktualisierungen erneut installiert werden, sollte die Fehlerursache behoben werden.

Wenn eine Datenbank zum Zeitpunkt des Installierens einer Softwareaktualisierung nicht verbunden war, dann konnten die Tabellen auf dieser Datenbank nicht aktualisiert werden. Damit besitzen diese noch die Tabellendefinition von vor der Aktualisierung, diese passt ggf. nicht zu den neu installierten Tabellenbeschreibungen.

Bemerken Sie diesen Fehler, bevor mit dem System weitergearbeitet wird, dann empfehlen wir die Wiederherstellung der Sicherung des Systems und das erneute Installieren der Softwareaktualisierungen.

In den Fällen, in denen das System nicht mehr wiederhergestellt werden kann, weil nach Erzeugung des inkonsistenten Zustands bereits wichtige weitere Daten auf dem System erfasst wurden, existiert keine vollständig sichere Lösung, das System wieder auf einen konsistenten Stand zu bringen. Die Objekte, deren Versionen der Tabellenbeschreibungen und Tabellendefinitionen abweichen, können gezielt auf die aktuellste Version gebracht werden. Das Vorgehen ist im Kapitel „Business Object reorganisieren“ beschrieben. Bei Systemen mit Produktivdaten wird dieses Vorgehen nicht empfohlen.

Eine weitere Entstehung für Versionsdifferenzen ist, wenn Sie beispielsweise eine veraltete Sicherung einer OLTP-Datenbank in ein aktuelleres System rückrücksichern. In diesem Fall sind die auf der Datenbank generierten Business-Object-Versionen älter als die aktiven Versionen im Repository des Systems.

3.3.2          Datenbanktabellen analysieren

Mit dem Tool chkdbt und der Option -analyseTables können Sie die Datenbanktabellen umfangreicheren Prüfungen unterziehen:

• Prüfung, ob das Schema der aktiven Datenbanktabelle der Tabellendefinition entspricht. Abweichungen zwischen der Tabellendefinition und dem Datenbankschema dürfen im normalen Betrieb nicht auftreten.
• Prüfung, ob zu der Tabellendefinition auch eine Tabellenbeschreibung existiert. Wenn zu einer Tabellendefinition keine Tabellenbeschreibung existiert, dann kann die Tabellendefinition und die Datenbanktabelle gelöscht werden.
• Die Analyse der Datenbanktabellen schließt auch die im Kapitel „Version der Datenbanktabellen prüfen“ beschriebenen Prüfungen ein.

Die Datenbanktabellen können Sie mit dem folgenden Befehl für alle Tabellen der Datenbank „DX“ analysieren.

chkdbt -analyseTables -table:% -db:DX

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen prüfen (chkdbt)“ zu dem Tool chkdbt.

Das Tool gibt alle Datenbanktabellen aus, die nicht die erwarteten Eigenschaften aufweisen:

Database DX initialised

 

Database: DX

=============================================

analysing tables

compare version

=============================================

 

OXA repository version VRA database version active VAA locked VLA

OXB repository version VRB database version active VAB

 

error while in table TXC:

schema compare:

Index not exists in definition C408NBVEIB000CIS

Index not exists in definition C508NBVEIB000CIS

 

error while in table TXD:

MISSING DESCRIPTION

Wenn zu einem Business Object die temporäre Tabelle erzeugt wurde, dann wird auch die Version der temporären Tabelle ausgegeben (siehe Objekt OXA). Auf einem Entwicklungssystem ist das ein normaler Zustand, wenn das Business Object in einer Entwicklungsaufgabe ist und generiert wurde. Auf Test- und Produktivsystemen sollten keine temporären Tabellen existieren.

Wenn Differenzen zwischen Tabellendefinition und Datenbankschema bestehen, dann werden diese detailliert ausgegeben (siehe Tabelle TXC).

Wenn zu einer Tabellendefinition keine Tabellenbeschreibung existiert (siehe Tabelle TXD), dann wird der Text „MISSING DESCRIPTION“ ausgegeben. Bei Entwicklungssystemen müssen Sie beachten, dass diese Meldung bereits erscheint, obwohl die Entwicklungsaufgabe noch nicht aktiviert ist.

Datenbanktabellen analysieren

Das Datenbankschema muss immer zu der Tabellendefinition passen. Wenn beispielsweise ein Index zur Leistungssteigerung manuell erfasst wird, dann wird dieser als Fehler beim Analysieren der Tabelle ausgegeben. Diese Abweichung wäre bekannt und erwünscht und könnte ignoriert werden. Bei allen anderen Abweichungen empfiehlt sich, mit dem Supportcenter Kontakt aufzunehmen.

Datenbanktabellen ohne Tabellenbeschreibung können, wie im Kapitel „Datenbanktabellen löschen“ beschrieben, gelöscht werden. Prüfen Sie vor dem Löschen, dass keines der Business Objects, dessen Datenbanktabellen Sie löschen möchten, in einer Entwicklungsaufgabe enthalten ist.

Wenn die Versionen der Tabellendefinition und der Tabellenbeschreibung abweichen, dann gehen Sie vor wie im Kapitel „Version der Datenbanktabellen prüfen“ beschrieben.

3.3.3          Lokalisierbare Attribute prüfen

Mit dem Tool rgzdbt und der Option -nlsTables können Sie prüfen, ob zu jeder Nebensprache in den NLS-Tabellen eines Business Objects eine Übersetzung besteht. Wenn Übersetzungen zu einer Nebensprache fehlen, dann werden die betroffenen Datensätze bei Suchen mit dieser Sprache nicht gefunden. Sie können die lokalisierbaren Attribute aller Business Objects auf der Datenbank „DX“ mit dem folgenden Befehl prüfen:

rgzdbt -nlsTables -db:DX -all

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen reorganisieren (rgzdbt)“ zu dem Tool rgzdbt.

Das Tool gibt alle NLS-Tabellen aus, in denen zu wenige oder zu viele Übersetzungen enthalten sind:

analyzing NLS tables of XA

analyzing NLS tables of XB

analyzing NLS tables of XC

XCUA deleted 4 nls objects

XCUA created 6 nls objects

XCUB deleted 4 nls objects

analyzing NLS tables of XD

Solange die vorhergehende Zeile mit analyzing NLS Tables beginnt, bedeutet die Meldung XCUA deleted 4 nls objects nicht, dass die Übersetzungen tatsächlich gelöscht werden. Die Meldung beschreibt, was beim Reorganisieren der NLS-Tabelle passieren würde.

Zu viele oder zu wenige Übersetzungen können aufgrund von Änderungen der Nebensprachen in der Konfiguration entstehen. Wenn sehr große Differenzen bei den Übersetzungen existieren, dann empfiehlt sich zu prüfen, ob die Konfiguration der Nebensprachen dieser Datenbank korrekt ist.

Wenn die Daten einer Datenbank mit SQL modifiziert werden, dann werden ggf. die zugehörigen Übersetzungen nicht erzeugt bzw. gelöscht.

Im Kapitel „Lokalisierbare Attribute reorganisieren“ wird beschrieben, wie Sie überflüssige Übersetzungen löschen und notwendige erzeugen können.

3.3.4          SBLOBs prüfen

Hinweis:
Seit Release 4 sollten SBLOBs nicht mehr verwendet werden. Daher ist im Allgemeinen unnötig, die SBLOBs zu prüfen.

Mit dem Tool rgzdbt und der Option -SBLOBs können Sie prüfen, ob ungültige SBLOB-Fragmente einer Datenbank existieren. Der folgende Befehl prüft alle SBLOBs auf der Datenbank „DX“:

rgzdbt -SBLOBs -db:DX

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen reorganisieren (rgzdbt)“zu dem Tool rgzdbt. Das Tool gibt aus, wie viele SBLOBs gültig bzw. ungültig sind:

TOTAL=379 INVALID=0 SBLOBs

Im normalen Betrieb können keine ungültigen SBLOBs erzeugt werden. Das ist nur durch Programmierfehler in der Anwendung oder aber durch die direkte Modifikation der Datenbank mit SQL möglich. Wenn zu viele ungültige SBLOBs existieren, dann setzen Sie sich mit dem Supportcenter in Verbindung.

3.3.5          Objektreferenzen prüfen

Mit dem Tool rgzdbt und der Option -objectReferences können Sie prüfen, ob ungültige Objektreferenzen bestehen. Ungültige Objektreferenzen haben keine negativen Auswirkungen. Mit dem folgenden Befehl werden alle Business Objects ausgegeben, zu denen Objektreferenzen existieren:

rgzdbt -objectreferences -db:DX

Ausgabe:

XA TOTAL=4 INVALID=0 ERROR=0

XB TOTAL=40 INVALID=6 ERROR=0

XC TOTAL=153 INVALID=19 ERROR=0

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen reorganisieren (rgzdbt)“zu dem Tool rgzdbt. Wenn sehr viele ungültige Objektreferenzen existieren, dann kann die Leistung des Gesamtsystems beeinträchtigt werden.

Wenn die Daten einer Datenbank mit SQL modifiziert werden, dann werden ggf. die zugehörigen Objektreferenzen nicht erzeugt bzw. gelöscht.

Im Kapitel „Objektreferenzen reorganisieren“ wird beschrieben, wie Sie ungültige Objektreferenzen löschen können.

3.3.6          Datenbankschema ausgeben

Sie können sich den Inhalt der Tabellendefinition mit dem Tool dspdbt wie folgt für ein Business Object „Y“ auf der Datenbank „DX“ ausgeben lassen:

dspdbt -o:Y -db:DX

Das Ergebnis ist beispielsweise die folgende Ausgabe:

Database DX initialised

 

Database: DX

=============================================

printing table schema

=============================================

 

Table         : LANGUAGE002

TimeDependent : NONE

CreationState : ACTIVE

Version       : active=1.0

Primary key   : GUID

Business key  : I00O0HDOKL500CIS00( ISOCODE )

Columns       :

GUID                                     :  Guid NOT NULL

ISOCODE                                  :  String(2)

DESCRIPTION                              :  String(65)

UPDATEINFO                               :  Boolean

MANAGINGSYSTEM                           :  Guid

UPDATEINFOXDELETETIME                    :  Timestamp

UPDATEINFOXUPDATETIME                    :  Timestamp

UPDATEINFOXCREATETIME                    :  Timestamp

UPDATEINFOXDELETEUSER                    :  Guid

UPDATEINFOXUPDATEUSER                    :  Guid

UPDATEINFOXCREATEUSER                    :  Guid

Die Tabellendefinition enthält immer die Daten der aktiven Tabelle und nicht die Daten der temporären Tabelle.

Die Daten bedeuten im Einzelnen:

Daten	Erklärung
Table	Der Name der Tabelle in der Datenbank. Der Tabellenname leitet sich von dem Namen der Objektbeschreibung ab.
TimeDependent	Gibt an, ob die Tabelle zeitabhängig ist.
CreationState	Der Generierungszustand zeigt an, ob die Tabelle gerade in Bearbeitung ist: ·         ACTIVE Die Tabelle ist aktiv und eine temporäre Tabelle existiert nicht. ·         CREATING Die temporäre Tabelle wird gerade erzeugt. ·         CREATED Die temporäre Tabelle wurde erfolgreich erzeugt. ·         CONVERTING Die Daten aus der aktiven Tabelle werden aktuell in die temporäre Tabelle konvertiert. ·         CONVERTED Die Daten der aktiven Tabelle wurden in die temporäre Tabelle konvertiert. ·         RELEASING Die temporären Tabellen werden gerade aktiviert. ·         RESTORING Die temporären Tabellen werden gerade gelöscht.
Version	Enthält die Versionsnummer der aktiven Tabellen (active) und der temporären Tabelle (locked).
Primary key	Name und Attribute des Primärschlüssels. Bei zeitabhängigen Tabellen inklusive VALIDFROM.
None	Name und Attribute der nicht eindeutigen Schlüssel.
Business key	Name und Attribute des Business keys. Bei zeitabhängigen Tabellen inklusive VALIDFROM.
Secondary key	Name und Attribute der Sekundärschlüssel. Bei zeitabhängigen Tabellen inklusive VALIDFROM.
Columns	Die Spaltennamen der Tabelle in der Datenbank. Die Spaltennamen leiten sich von den Namen der Attribute in der Objektbeschreibung ab.

Mit diesem Tool können Sie sich gezielt den Erzeugungszustand und das Datenbankschema eines Business Objects ausgeben lassen.

3.3.7          Datenbankinformationen ausgeben

Sie können sich die Datenbankinformationen mit dem Tool dspdbt wie folgt für eine Datenbank „DX“ ausgeben lassen:

dspdbinf -db:DX

Das Ergebnis ist beispielsweise die folgende Ausgabe:

Database DX initialised

 

Database information DX

System                     : SX

ContentLanguage            : de

ContentType                : OLTP-Daten

DatabaseType               : DB2 UDB for iSeries

SecondaryLanguages         : en it

SecondaryDisplayLanguages  : fr en hu it sk pl

Die Daten bedeuten im Einzelnen:

Daten	Erklärung
System	Name des Systems, zu dem die Datenbank gehört.
ContentLanguage	Primärsprache der Datenbank
ContentType	Inhalt der Datenbank
DatabaseType	Treiber, mit dem die Datenbank erstellt wurde.
SecondaryLanguages	Nebensprachen der Datenbank.
SecondaryDisplayLanguages	Nur auf OLTP-Datenbanken verfügbar. Nebensprachen der Repository-Datenbank zusammen mit den Nebensprachen der OLTP-Datenbank.

3.4               Fehlerkorrektur

Nachdem Sie den Fehler vollständig analysiert haben, müssen Sie, bevor Sie Maßnahmen zur Fehlerkorrektur ergreifen, eine vollständige Sicherung des Systems durchführen. Reparaturmaßnahmen können bei falscher Anwendung Daten in dem System irreparabel zerstören. Aus diesem Grund sollten Sie nach jeglicher Fehlerkorrektur das System ausreichend testen.

3.4.1          Business Object reorganisieren

Sie können die Datenbanktabellen eines Business Objects mit dem Tool rgzbo aus der aktuellen Tabellenbeschreibung neu erzeugen. Das Tool rgzbo darf nicht verwendet werden, wenn das Business Object in einer Aufgabe aufgenommen ist oder gerade von einer Softwareaktualisierung generiert wird.

Sie müssen die Tabellen neu generieren, wenn die Tabellendefinition veraltet ist, d. h. wenn die Tabellenbeschreibung aktueller ist als die Tabellendefinition. Im Kapitel „Version der Datenbanktabellen prüfen“ wird beschrieben, wie Sie alle veralteten Tabellen finden.

Mit dem folgenden Aufruf können Sie das Business Object „XYZ“ auf der Datenbank „DX“ reorganisieren:

rgzbo -o:XYZ -db:DX

Wenn die Version der Tabellendefinition bereits der Version der Tabellenbeschreibung entspricht, dann wird das Business Object nicht neu erzeugt. Mit der Option -force können Sie diese Prüfung umgehen. Die Verwendung der Option -force wird ohne Rücksprache mit dem Supportcenter nicht empfohlen.

Nach der Reorganisation von Business Objects müssen Sie alle ERP-System-Application-Server (SAS) im System neu starten, da sich das Schema der Datenbanktabellen geändert hat.

Mit dem folgenden Aufruf reorganisieren Sie alle Business Objects, deren Tabellendefinition veraltet ist:

rgzbo –all –db:DX –parallelUpdate:4

Die Business Objects werden in mehreren Threads parallel reorganisiert. Die parallele Reorganisation der Business Objects kann die Ausführungszeit beträchtlich senken.

Beim Reorganisieren eines Business Objects werden bei Versionsänderungen durch die Tools cnvbo und upgaps Updateprogramme ausgeführt. Datenaktualisierungen werden nicht automatisch ausgeführt. Nach dem Sie ein Business Object reorganisiert haben, sollten Sie über die Anwendung „Datenaktualisierungen abfragen“ prüfen, ob Sie noch Datenaktualisierungen auf der Datenbank ausführen müssen. Wenn das Schema einer Datenbank veraltet ist, wurden häufig auch die zugehörigen Datenaktualisierungen nicht aufgerufen.

Hinweis:

Stellen Sie sicher, dass Sie als einziger Benutzer auf dem System angemeldet sind, wenn Sie das Tool rgzbo verwenden. Verwenden Sie das Tool rgzbo niemals, wenn andere Benutzer oder Verarbeitungsaufträge auf dem System arbeiten.

Sie sollten nach der Reorganisation eines Business Objects insbesondere die Anwendungen testen, die das Business Object bzw. das zugehörige Business Entity verwenden.

3.4.2          Lokalisierbare Attribute reorganisieren

Mit dem Tool rgzdbt und den Optionen -nlsTables und -modify stellen Sie sicher, dass zu jeder Nebensprache in den NLS-Tabellen eines Business Objects eine Übersetzung existiert. Wenn Übersetzungen zu einer Nebensprache fehlen, dann werden die betroffenen Datensätze bei Suchen mit dieser Sprache nicht gefunden. Weiterhin werden Übersetzungen gelöscht, zu denen das Business Object gelöscht wurde oder die zu keiner der Nebensprachen der Datenbank gehören. Mit dem folgendem Befehl reorganisieren Sie die NLS-Tabellen aller Business Objects auf einer Datenbank.

rgzdbt -nlsTables -modify -db:DX -all

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen reorganisieren (rgzdbt)“.

Das Tool gibt alle NLS-Tabellen aus, die reorganisiert werden:

reorganizing NLS tables of XA

reorganizing NLS tables of XB

reorganizing NLS tables of XC

deleting 4 nls objects

XCUA deleted 4 nls objects

creating 6 nls objects

XCUA created 6 nls objects

deleting 4 nls objects

XCUB deleted 4 nls objects

reorganizing NLS tables of XD

Bevor Sie die lokalisierbaren Attribute reorganisieren, sollten Sie unbedingt prüfen, ob die Einstellungen der Nebensprachen für diese Datenbank in der Konfiguration korrekt sind. Wenn eine Nebensprache von Ihnen aus der Liste der Nebensprachen entfernt wurde, dann werden die Übersetzungen unwiederbringlich gelöscht. Wenn Sie eine neue Nebensprache hinzugefügt haben, dann wird diese mit dem Wert aus der Primärsprache der Datenbank initialisiert. Sie müssen ebenfalls sicherstellen, dass die Datenbankinformationen mit den Konfigurationsdaten übereinstimmen. Wenn Abweichungen bestehen, dann wird beim Start des ERP-System-Application-Servers (SAS) eine Fehlermeldung ausgegeben.

Sie sollten nach dem Reorganisieren der lokalisierbaren Attribute stichprobenweise die betroffenen Business Entitys kontrollieren, ob die Übersetzungen Ihren Erwartungen entsprechen.

3.4.3          Objektreferenzen reorganisieren

Mit dem Tool rgzdbt und den Optionen -objectReferences und -modify können Sie ungültige Objektreferenzen löschen. Mit dem folgenden Befehl werden die Objektreferenzen gelöscht, die auf ein nicht existentes Business Object zeigen:

rgzdbt -objectreferences -modify -db:DX

Ausgabe:

deleting 25 object references

XA TOTAL=4 INVALID=0 ERROR=0

XB TOTAL=40 INVALID=6 ERROR=0

XC TOTAL=153 INVALID=19 ERROR=0

Weitere Informationen entnehmen Sie der Dokumentation „Datenbanktabellen reorganisieren (rgzdbt)“.

Sie sollten die Objektreferenzen nur dann reorganisieren, wenn Sie aufgrund einer Leistungsanalyse diese als Problem erkannt haben.