Grosse und kleine Fehler in Forms 4.5 Erfahrungsbericht: Oracle-4GL unter Windows 3.1 eingesetzt

24.11.1995

Mit rund 90 von 600 Manntagen schlugen die Fehler in dem Oracle- 4GL-Tool "Forms 4.5" bei unserem Projekt zu Buche, resuemiert Friedemann Weik*. Er schildert den Leidensweg vom Einsatz des ersten Beta-Release bis zu aktuellen Problemen mit der neuesten Version des Werkzeugs.

Eigentlich waren wir gewarnt, denn auf der Konferenz der Deutschen Oracle Anwendergruppe (Doag) 1994 gab es einen Vortrag ueber die groessten Fehler in der Version 4.0 des 4GL-Werkzeugs. Doch letztlich liessen wir uns ueberzeugen. Probleme bei der Produktdemonstration wurden dem Vorfuehreffekt zugeschrieben.

Das Projekt umfasste die Erstellung einer Angebotsbearbeitung mit Zugriff auf die Oracle-Datenbank und die Einbettung der Microsoft- Office-Produkte "Excel" und "Winword". Als Plattform diente Windows 3.x. Die Entwicklung betraf 90 Tabellen, 70 Masken und 2050 Spalten, wovon 1000 unterschiedlich waren.

Der Auslieferungstermin wurde auf Ende Mai 1995 festgesetzt. Ende Dezember 1994 schlossen wir mit der Oracle Deutschland GmbH einen Vertrag ueber den Einsatz einer Betaversion der Entwicklungs-Tools "CDE 2". Der Anbieter stellt uns jedoch die baldige Freigabe der Endversion in Aussicht.

Die Betaausfuehrung war schlichtweg nicht installierbar. Mitte Januar 1995 erreichte uns ein Vorab-Release des Endprodukts. Mit dieser Version haben wir bis Ende Januar 1995 die fuer uns relevanten Funktionen von Forms 4.5 getestet.

Zunaechst blieb unklar, wie das Windows-Steuerelement "Combo-Box" zu installieren war. Schliesslich stellten wir fest, dass es nicht wie erwartet funktioniert. Es war und ist nicht moeglich, Werte einzugeben, die nicht bereits als Option im Kombinationsfeld genannt sind, wie es in Windows-Programmen ueblich ist.

Ausserdem sind indizierte VBX-Funktionen nicht ansprechbar. Das liegt daran, dass das Call-Interface zu wenige Parameter besitzt, teilte Oracle mit. Die Folge: Auf den Einsatz von Struktur-VBX, die etwa bei der Directory-Anzeige in Dialogfeldern von Windows- Programmen vorkommen, musste verzichtet werden.

Der Report-Generator verbrauchte im "Designer"-Teil sowie auch teilweise zur Laufzeit mehr Windows-Ressourcen als verfuegbar. Dadurch verabschiedete sich Windows ohne Fehlermeldung. Statt "Reports" setzten wir Excel und Winword zur Druckaufbereitung und -ausgabe ein.

Zudem konsumierte der "Forms-Designer" selbst reichlich Windows- Ressourcen, die auch nach Beendigung der Arbeit mit dem Tool nicht alle freigegeben wurden und waehrend des Gebrauchs immer weiter abnahmen. Demzufolge war ein regelmaessiger Neustart von Windows erforderlich, falls er nicht durch andere Fehler bereits erzwungen worden war.

Beim Test mit echten Anwendungsdaten gab es unangenehme Ueberraschungen. Der Versuch, eine fuenfstellige Zahl in einem zweistelligen numerischen Eingabefeld zu speichern, ergab nicht nur den zu erwartenden Truncation-Error. Das System quittierte unsere Bemuehungen mit der Fehlermeldung "In Ihrer Anwendung ist eine Speicherschutzverletzung aufgetreten. Bitte schliessen Sie die Anwendung." Als Reaktion auf diese Meldung ist ein Neustart des Rechners, in einigen Faellen sogar ein Nachladen der Forms-*.DLL- Dateien angeraten.

Die Kommunikation via Dynamic Data Exchange (DDE) funktionierte nicht, ausser im Debugger. Die Ursache dafuer war laut Hotline ein "Vergessen" des Termination-Strings. Das bedeutete fuer uns: Warten auf neues Release!

Im Juni prueften wir die Version 4.5.6.0.7 des Entwicklungstools Cooperative Development Environment (CDE), jetzt von Oracle in "Developer/2000" umbenannt. Der DDE-Fehler war behoben, und die Kommunikation funktionierte, wenn auch nur mit sehr langen Time- out-Zeiten.

Der Ressourcenverbrauch von Forms war deutlich geringer geworden, dafuer verbrauchte das Tool mehr Page-Speicher. Doch insgesamt nahmen die Neustarts ab. Der Versuch allerdings, ein Zeichen auf dem Hintergrund (Canvas) einzugeben, fuehrte zu einer sofortigen Speicherschutzverletzung in der TK21WIN.DLL. Der Zeichensatz "WE8PC850" aus der Datei Oracle.ini war bislang ein Default-Wert. Die aktuelle Version kannte diesen nicht, so dass er in "WE8ISO8859P1" geaendert werden musste.

Ausserdem funktionierten nun zum Teil die Combo-Boxen nicht mehr, sondern ergaben beim Ausfuehren die Fehlermeldungen "Error populating group" oder "value error", verbunden mit "query caused no records...", weil in der jeweiligen Abfrage geprueft wurde, ob der Wert in der Combo-Box-Liste eingetragen war.

In der Endphase des Projekts, Anfang August 1995, zeigten sich auch in der OLE-2-Implementierung Fehler. So war es unmoeglich, mit Hilfe von OLE-2-Befehlen aus einer Tabelle ein leeres Binary Large Object (BLOB) zu initialisieren und anschliessend aus Winword oder Excel zu starten. Ausserdem "bemerkte" Forms die Eingabe in BLOBs nicht, wenn die Bearbeitung aus dem Anwendungsprogramm gestartet wurde. Scheinbar unveraenderte Datensaetze wurden beim Verlassen des Blocks nicht gespeichert, sondern verworfen.

Dazu kam, dass sich ein gefuelltes BLOB mit OLE-2-Befehlen nicht nachbearbeiten liess. Mit Hilfe von DDE ist das sowieso unmoeglich, da DDE grundsaetzlich keine BLOBs unterstuetzt.

Mitte September 1995 haben wir die neue Forms-Version 4.5.6.3.3 installiert. Alle Module muessen neu generiert werden, da sonst waehrend der Ausfuehrung Texte vom Canvas verschwinden. Das Hilfe- Feature, das urspruenglich in Anlehnung an ein Demomodul realisiert wurde, funktioniert nicht mehr. Ein Fehler in der Zeichensatzdefinition fuehrt nicht laenger zum Crash, sondern dazu, dass die Form ohne Interaktionsmoeglichkeit "durchlaeuft" und wieder verschwindet.

Wer mit Erwartungen hinsichtlich Objektorientierung an Forms herangeht, wird enttaeuscht. In der objektorientierten Programmierung ist es moeglich, Events und die entsprechenden Programmfunktionen anzustossen. Das "Event-Propagation" genannte Verhalten dient etwa dazu, das Feld eines Blockes so zu aendern, dass es einen Validate-Trigger aktiviert. Mit Forms wird der Validate-Trigger auch dann ausgeloest, wenn es unnoetig ist, zum Beispiel nach einem Query. Der Trigger reagiert jedoch nicht, wenn der Feldinhalt mit PL-SQL ueberschrieben wird.

*Friedemann Weik ist Bereichsleiter bei der HBT GmbH in Hamburg. Der vollstaendige Bericht findet sich in den Doag-Proceedings 1995.

Einige aktuelle Probleme mit Forms 4.5

- Vergisst ein Programmierer beim Editieren des PL-SQL-Codes ein Semikolon, bemerkt der Compiler das und fordert zur Korrektur auf. Diese ist einfach und scheinbar erfolgreich. Nach dem Speichern tauchen jedoch dieselben Fehler auf, da das Aendern von wenigen und hier insbesondere von Sonderzeichen beim inkrementellen Speichern uebersehen wird.

- Beim Kopieren von Blockfeldern oder Eigenschaften wird die interne Struktur so veraendert, dass Forms die betreffende Datei nicht mehr speichern kann.

- Wird eine Maske nach einem "Compile-All" oder "Generate" gespeichert, ist die Datei groesser als beim Sichern nach einem "Disconnect". Das liegt daran, dass im ersten Fall das System das Compile-Ergebnis mitablegt, waehrend es im zweiten Fall alle Compile-Ergebnisse loescht.

Soll im Designer eine solche Datei geoeffnet werden, misslingt der Zugriff wegen eines fehlenden Connects. Forms versucht dann, rekursiv seine Module neu zu uebersetzen, was wegen der fehlenden Compile-Ergebnisse nicht gelingen kann. Der Versuch wiederholt sich mit jedem bereits uebersetzt gespeicherten Modul. Derartige Situationen entstehen, wenn per Doppelklick der Forms-Designer aus dem Windows-Datei-Manager gestartet werden soll.

- Ausserdem gibt es keinen Mechanismus, der beim Ausfuehren von Forms ueberprueft, ob die benutzte Library richtig und gueltig ist. Ist sie es nicht, erscheint deshalb keine qualifizierte Fehlermeldung, sondern ein Windows-Statement zur Speicherschutzverletzung.

- Forms 4.5 haelt alle in einer Maske benutzen Cursor offen. Dadurch werden die typischen Groessen aus der Datei Init.ora erheblich ueberschritten, und der Anwender erhaelt irritierende Fehlermeldungen. Benoetigen die Fehlerroutinen einen Cursor, folgen rekursive Fehler in einer Endlosschleife.