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:

   • Beim Auspacken mit grafischen Packprogrammen (wie WINZIP) kann es unter Umständen passieren, daß die Verzeichnisstruktur nicht wiederhergestellt wird, sondern alle Dateien in ein Verzeichnis entpackt werden. Das führt dann dazu, daß Skripte nicht ordnungsgemäß funktionieren. Für diesen Fall steht das frei erhältliche Programm UNZIP.EXE (im admin\tool-Unterverzeichnis oder auf Anfrage in Gießen erhältlich) zur Verfügung. Dieses Programm wird von der Eingabeaufforderung im GTDS-Verzeichnis gestartet.
   • Z.B. beim Auspacken mit dem Windows-Explorer möchte das Auspack-Programm die Dateien in ein Unterverzeichnis mit dem Namen der ZIP-Datei erstellen. Dadurch würde quasi kein Update/Patch installiert. Also unbedingt das Zielverzeichnis kontrollieren
   • Im Allgemeinen ist es hilfreich, einen Entpacker zu nehmen, der die Zeitstempel der Dateien bewahrt. Das erleichtert bei Fehlersuchen die Versionskontrolle.
   • Es darf kein GTDS laufen, welches Dateien in diesem Verzeichnis liest, weil geöffnete Dateien gegebenfalls nicht überschrieben werden und somit das Update evtl. nicht vollständig installiert wird. Dies ist vor allem bei zentral installierten GTDS-Dateien zu berücksichtigen. Es müssen also alle Benutzer das GTDS verlassen. Eventuell ist es empfehlenswert, das Update auch zuerst an einer lokalen Kopie einzuspielen und dort auszuprobieren.
   • Dieses Vorgehen muß für alle GTDS-Verzeichnisse durchgeführt werden, da die Anwendung zur Datenbank passen muß. Weitere GTDS-Verzeichnisse können sich lokal auf Rechnern oder auf unterschiedlichen Citrix-Servern o.ä. befinden.

   Hinweis:

   • Wurde ein Update übersprungen, müssen die "Zwischen-Updates" ebenfalls durchgeführt oder gegebenenfalls, falls verfügbar, ein komplettes GTDS eingespielt werden.
   • Dabei ist es wichtig, auch die "übersprungenen" Datenbankänderungen (siehe nächster Punkt) in der zeitlch korrekten Reihenfolge durchzuführen. Die Maske stellt hierzu für Updates ab dem 10.3.2000 eine Möglichkeit bereit.
   • Überprüfen Sie auch die Notwendigkeit des Durchführens von "Spezialskripten".

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:
   • ältere Updates durchführen: wurden Updates übersprungen, so müssen diese zunächst in der angegebenen Reihenfolge durchgeführt werden (nicht alle, nur die Notwendigen!).
     (Dabei werden die entsprechenden Skriptsammlungen "updlist_bis_???????.sql " im SQL-Unterverzeichnis aufgerufen; es entstehen die Log-Dateien updlist_bis_???????.txt.)
   • Datenbank-Update durchführen
     (Dabei wird die SQL-Skriptsammlung "updlist.sql" im SQL-Unterverzeichnis aufgerufen. Es entsteht die Log-Datei up<ttmmjj>.log)
   • Spezialskripte ausführen: Überprüfen Sie, welche Spezialskripte für Sie in Frage kommen.
4. Das Einlesen geänderter Systemtabellen wird nicht automatisch gestartet, da gegebenenfalls selbstdefinierte Inhalte überschreiben werden könnten.

Hinweis:
• Neuere Updates lesen geänderte oder neue Systemtabellen evtl. über SQL*Plus-Skripte im Punkt "Spezialskripte" ein. Die folgenden Punkte gelten für das Einlesen sogenannter Export-(DMP-)Dateien.
• Um die dort angesprochenen Skripte ausführen zu können, müssen Sie das DMP-Verzeichnis über einen Laufwerkspfad (lokales oder Netzwerklaufwerk) ansprechen können, da diese in der MS-DOS-Eingabeauforderung laufen. Darüber hinaus muß das Verzeichnis für Sie schreibberechtigt sein.
• Desweiteren muß auf dem GTDS-Client eine zur Datenbankversion passende Version der ORACLE-Client-Software (das ist nicht die Laufzeitumgebung des GTDS) vorhanden sein (insbesondere sqlplus.exe, imp.exe und exp.exe für ORACLE 8 bzw. plus33.exe, imp73.exe und exp73.exe für ORACLE 7.3). Die Batch-Dateien tr_table.bat und tab_ers.bat müssen auf die jeweilige Datenbankversion angepaßt werden, da sie diese Versionen aufrufen.
• Falls die Voraussetzungen nicht zutreffen, muß ein entsprechendes Skript auf dem Server durchgeführt werden. Für UNIX-Systeme kann dieses über die bekannte Webseite bezogen werden.
5. 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.
6. 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

• Allgemeines zur GTDS-Bedienung
• Einrichten von GTDS-Rollen
• Vergabe von PUBLIC SYNONYMen und Rechten
• Dynamische Module