Einspielen eines GTDS-Updates oder Patches

GTDS-Updates werden als ZIP-Dateien, eventuell verpackt als selbstextrahierende Archive, verteilt, bzw. sind von der GTDS-Webseite abrufbar.

Vor dem Einspielen eines Updates steht immer die Datensicherung. Bitte stellen Sie sicher, daß ein aktueller und fehlerfreier Export existiert. Dies gilt insbesondere in Bezug auf möglicherweise auftretende Probleme mit bestimmten Datenbankversionen, die vor allem bei umfangreichen Updates auftreten können. Diese sind allerdings kaum noch im Einsatz.

Definition GTDS-Verzeichnis:. Im folgenden ist öfters von "GTDS-Verzeichnis" die Rede. Das GTDS-Verzeichnis ist das Verzeichnis, in dem sich die Anwendung befindet. Meist heißt es "gtds". Da die Anwendung zum großen Teil aus FMX-Dateien besteht, sind dort viele Dateien mit dieser Endung zu finden.

Häufig (wenn GTDS als "Instant-Client", d.h. ohne lokale Installation, läuft) befindet sich darüber ein Verzeichnis, in dem sich die Aufruf-Dateien befinden. Dieses darf nicht mit dem GTDS-Verzeichnis verwechselt werden. In folgender Grafik ist das GTDS-Verzeichnis das Verzeichnis "gtds" in diesem Aufruf-Verzeichnis.

Vorgehen

  1. Sicherung der GTDS-Programmdateien. Am bequemsten ist das Kopieren (nicht Verschieben, da ein Update nicht alle Dateien enthält) des gesamten Verzeichnisbaumes des GTDS-Verzeichnisses an eine andere Stelle. Wenn GTDS dann einige Zeit problemlos läuft, kann dieses Verzeichnis wieder gelöscht werden.
  2. Kopieren der Archivdatei mit dem Update in das GTDS-Verzeichnis und Auspacken dieser Datei. Wenn es sich um ein selbstextrahierendes Archiv (Endung ".exe" handelt, geschieht dies über Aufruf der Datei im GTDS-Verzeichnis. Dazu holen Sie sich eine (MSDOS-) Eingabeaufforderung und rufen die Datei, meist mit dem Namen up*.exe auf.

    Achtung:

    Hinweis:

  3. Weiter geht es mit dem Schritt 2 auf der folgenden Maske. Auch bei diesem Schritt ist es im Prinzip erforderlich, daß alle anderen Benutzer GTDS verlassen, um Tabellenänderungen durchführen zu können.
    Wichtig: Sie müssen die Schreibberechtigung auf das GTDS-Verzeichnis und seine Unterverzeichnisse haben, damit die jeweils entstehenden Log-Dateien geschrieben werden können. Außerdem muß SQL*Plus installiert und ggf. in der gtds.ini konfiguriert sein.
    Führen Sie alle Schritte in der vorgesehenen Reihenfolge aus:
  4. Das Einlesen geänderter Systemtabellen wird nicht automatisch gestartet, da gegebenenfalls selbstdefinierte Inhalte überschreiben werden könnten.

  5. Hinweis:
  6. Um etwaige neue Tabellen etc. an alle GTDS-Benutzer bekannt und bearbeitbar zu machen, müssen PUBLIC SYNONYMe und Rechte vergeben werden. Dieser Schritt wurde in die UPDATE-Verarbeitung integriert und ist im Normalfall nicht mehr erforderlich.
  7. Dynamische Module werden ebenfalls gesondert eingeladen und aktiviert, da hier zentrumsspezifische Anpassungen zu erwarten sind.

Hauptmaske für das Einspielen eines GTDS-Updates

Untermaske für das Durchführen vorheriger Updates und das Ausführen von Spezialskripten

Tabellen

keine

Probleme mit bestimmten Oracle-Versionen

Seit längerer Zeit ist ein Problem mit bestimmten Versionen von Oracle7 ("LONG - Felder - Fehler") bekannt. Eine Abhilfe ist nach unserer Kenntnis nur durch Wechsel auf eine andere (i.d.R. höhere) Version von Oracle7 möglich.

Betroffen sind vorwiegend Oracle7(®)- Datenbanken der Version 7.1.6 und 7.2.

Dies äußert sich in der Weise, daß im GTDS ohne erkennbaren Grund Eingabemasken "blockieren" und keine Abhilfe außer Neustart des Programmes möglich ist. Immer ist mindestens eine Tabelle in der Maske angesprochen, die ein Feld des Datentyps LONG enthält. Daß diese Tabelle die Quelle des Übels ist, kann man leicht in SQL*Plus verifizieren.

Ist z.B. Tabelle TUMOR betroffen, so ist in SQL*Plus ein

SQL> select Beurteilung from TUMOR;

ohne weiteres möglich, während

SQL> select Beurteilung from TUMOR for Update

sich aufhängt oder falsche Daten liefert. Der einzige bekannte "Workaround" ist bei den meisten Anwendern bekannt - Tabelle exportieren, löschen, re- Importieren.

Leider tritt dieser Fehler gehäuft auf nach ALTER TABLE - Statements auf die betreffenden Tabellen, wie sie bei einem Update notwendig sind. Entsprechend müssen Sie damit auch nach diesem Update rechnen, wenn Sie eine der gefährdeten Oracle-Versionen verwenden, und zwar ganz gleich, ob Sie die alphanumerische oder die grafische Version des Updates verwenden.

Betroffene Tabellen sind vorwiegend TUMOR, VERLAUF, OPERATION, BESTRAHLUNG, INTERNISTISCHE_THERAPIE und VORGESEHENE_MASSNAHME. Möchten Sie alle wissen, die in Frage kommen, gibt die SQL-Abfrage

SQL> select Table_Name from USER_TAB_COLUMNS where Data_Type='LONG' ;

Auskunft.

Entsprechend wird dieses "Aufhängen" vorwiegend in den Masken für Diagnosedaten, Verlaufsdaten, Strahlentherapie und vorgesehene Maßnahmen zu beobachten sein. Der Export und Re-Import einer solchen Tabelle kann in der alphanumerischen Umgebung mit dem Shell-Programm long_exp_imp2.ksh durchgeführt werden. Für die grafische Umgebung existert die Batchdatei tabexpimp.bat (plus rentable.sql und rentable.bat). Vor der Anwendung empfiehlt sich eine tel. Rückfrage in Gießen. Obwohl auch hier Exporte der Tabellen durchgeführt werden, ist es wichtig, sich vorher vom Vorhandensein fehlerfreier Datensicherungen zu überzeugen.

Wenn Sie eine Oracle-Datenbank der Version 7.1.6 oder 7.2 verwenden und über einen Wartungsvertrag mit Oracle verfügen, empfehlen wir Ihnen, bald ein Software-Upgrade durchzuführen (z.B. auf 8.1.5 bei rein grafischem GTDS oder auf 7.3.4 , wenn Sie noch alphanumerische Anwender haben ). Setzen Sie Oracle7 Version 7.1.3 oder 7.1.4 ein, sollten Sie nicht auf eine der genannten Versionen wechseln!

Änderungen

9. Februar 2001 Weitere Funktionen zum Nachholen vorheriger Updates und das Ausführen von Spezialskripten
11. November 2000 Weitere Funktionen, z.B. zur Einrichtung des Rollenkonzeptes
10. März 2000 Hilfe erstellt

Weitere Themen