Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.01.1994 - 

Die Anpassung an das GUI verlangt Fingerspitzengefuehl

Umstieg von Dbase nach Foxpro mit Stolpersteinen gepflastert

Das Gros der Umsteiger von Dbase nach Foxpro rekrutiert sich aus Herstellern von Datenbankapplikationen sowie groesseren Unternehmen, die ihre Anwender ohne Medienbruch in eine Windows-Umgebung versetzen wollen. Doch von einer glatten Umstellung kann kaum die Rede sein: Probleme tauchen besonders bei der Adaption der alphanumerischen Anwendung an die grafische Benutzeroberflaeche auf.

Foxpro fuer Windows sei voll kompatibel zu Dbase III+ und mit kleinen Einschraenkungen auch zu Dbase IV, heisst es bei Microsoft. Der Anwender koenne ohne neues Programmieren und ohne kostspielige Schulungen mit seinen kompletten Datensaetzen auf Foxpro umsteigen. Doch ganz so glatt, wie Microsoft es glaubhaft machen will, geht es leider nicht. Zwar bietet der Hersteller eine Reihe von Hilfen an - die Konzeptunterschiede im Look and feel einer grafischen Oberflaeche im Vergleich zu einer alphanumerischen Benutzer- Schnittstelle muss der Anwender jedoch selbst von Hand bewaeltigen.

Der Uebergang einer Datenbankanwendung von Dbase auf Foxpro laesst sich in zwei Stufen vollziehen:

- Der "technische" Umstieg liefert mit geringem Aufwand eine lauffaehige Version des Programms, allerdings mit erheblichen Einschraenkungen im Bereich Gestaltung und Bedienung.

- Die durchgaengig Windows-konforme Loesung erfordert einen Aufwand, der insbesondere von einer konsequenten Konzeptumsetzung auf das ereignisorientierte (Callbacks) Windows-Benutzermodell verursacht wird.

Der rein technische Umstieg erfolgt "kochrezeptartig" und ist deshalb relativ einfach zu bewaeltigen. Die erste lauffaehige Foxpro-Version stellt eine identische Abbildung des urspruenglichen Dbase-Programms dar.

Das Erscheinungsbild haengt stark davon ab, wie in Dbase programmiert wurde.

Programmteile, in denen die Ein- und Ausgabe mit den Befehlen "Say", "Text" beziehungsweise "Get" gesteuert wird, werden als fensterfreie Windows-Oberflaeche wiedergegeben. Dabei koennen allerdings Teile der Beschriftung verlorengehen oder Feldinhalte abgeschnitten werden.

Funktionen wie "Edit" werden dagegen automatisch sehr elegant als funktional reichhaltige Windows-Fenster umgesetzt. Dbase-Masken (Formate) muss der Programmierer mit Hilfe eines Konverters in das Foxpro-Format uebertragen.

Um aus einer Dbase-Anwendung eine durchgaengig Windows-konforme Datenbankapplikation zu erhalten, ist eine Reihe zusaetzlicher Vorarbeiten erforderlich. Der Entwickler muss neue Masken als Ersatz fuer die bislang "formatfreie" Ein- und Ausgabe erstellen.

Diese Windows-Fenster sollten in ihrem Erscheinungsbild so gestaltet werden, wie der Benutzer sie auch von anderen Windows- Programmen her kennt. Beispiele dafuer sind die Buttons "O.k." und "Abbruch". Diese Arbeiten erfordern einen nicht zu unterschaetzenden Aufwand.

Mangelnde Erfahrung wird mit Lehrgeld bezahlt

Es empfiehlt sich, zunaechst einen Styleguide zu erstellen, der als Grundlage fuer die neue Benutzer-Schnittstelle dient. Er sollte jedoch nicht nur Vorgaben zum Einsatz und zur Anordnung von Windows-Standards umfassen. Er muss auch beruecksichtigen, wie der Aufwand fuer den "gestalterischen" Umstieg mit Blick auf das vorliegende Programm moeglichst gering gehalten werden kann, ohne dass eventuelle Abstriche allzu negativ ausfallen.

In der Praxis treten hier aufgrund mangelnder Erfahrung die meisten Fehler auf. Die Folge ist ein unbefriedigendes Look and feel der Datenbankanwendung. Da funktional eigentlich nichts geaendert wurde, staunt das Management am Ende oft ueber das bezahlte Lehrgeld. Der Rueckgriff auf Mitarbeiter oder Softwarehaeuser, die bereits auf diesem Gebiet gearbeitet haben, hilft Kosten und insbesondere auch das Risiko senken.

Soweit es vom Konzept her technisch moeglich ist, erfuellt das Migrationswerkzeug fuer Bildschirmmasken, das Microsoft zur Verfuegung stellt, seine Aufgabe. In der Praxis entstehen die Probleme bei sehr vollen Masken:

- Die Schrift ist im Verhaeltnis zu den uebrigen Proportionen der Maske groesser geworden, so dass Fuehrungstexte abgeschnitten werden.

- Feldinhalte finden im Feld nicht mehr genuegend Platz.

- Spaltenueberschriften sind verrutscht.

- Die relative Maskengroesse hat sich geaendert, so dass die Legende, die in Dbase ueber "Page down" erreichbar war, nun zumindest teilweise sichtbar ist.

- Die Umlaute werden bei der Portierung in Abhaengigkeit von den verwendeten Fonts unterschiedlich veraendert.

Damit eine wirklich akzeptable Maske entsteht, sollte die manuelle Ueberarbeitung nicht nur die genannten Probleme beheben, sondern echt Verbesserungen bewirken. Dazu gehoeren beispielsweise die Einfuehrung von sogenannten Popups, die Zuordnung der Legende zur Funktionstaste F2 sowie die Einfuehrung eines O.k.- und eines Abbruch-Buttons, der in Tradition zur bisherigen Anwendung mit "Esc" beschriftet sein kann.

Masken-Nachbearbeitung verhindert Eingabefehler

Es empfiehlt sich, die Maske der Foxpro-Version nicht komplett neu, sondern aus der mechanisch migrierten Dbase-Maske zu erstellen. Hierdurch werden Eingabefehler (falscher Feldname) vermieden. Zum Verschieben und Vergroessern der Felder ist es ratsam, anstelle der Maus die Cursor-Tasten zu benutzen, da es sich mit ihnen feinfuehliger und praeziser arbeiten laesst.

Mit der Einfuehrung des O.k.- und Abbruch-Buttons stellt sich ein zusaetzliches Problem: Bei Dbase wird die Maske nach Ausfuellen des letzten Feldes verlassen. Drueckt der Benutzer zuvor auf die Esc- Taste, so beendet er die Maske sofort, ohne eine Aenderung des Datensatzes in der Datenbank. In Foxpro gibt es dagegen kein letztes Feld. Vielmehr wird das Verlassen ueber die Feldeigenschaft "Terminate Read on Selection" gesteuert. Unter Windows laesst sich diese Feldeigenschaft dem O.k.-Button zuordnen.

Der "Abbruch"-Knopf, als Ersatz fuer die Esc-Taste, fuehrt zu weiteren Schwierigkeiten. Der Programmierer hat explizit da-fuer zu sorgen, dass bei "Abbruch" der geaenderte Datensatz nicht versehentlich in der Datenbank landet. Zu diesem Zweck muss - unter Benutzung der Funktionen "Scatter Memvar" und "Gather Memvar" - zunaechst im Speicher gearbeitet werden, was wieder-um zu einer Aenderung aller Feldnamen in der Maske fuehrt; erst bei Druecken von "O.k." werden die Daten aus dem Speicher in die Datenbank uebernommen.

Bei Umstellungsprojekten mehrerer Anwender zeigten sich auch Schwierigkeiten mit dem Migrationswerkzeug fuer Reports. Da die Probleme nicht ohne weiteres zu klaeren waren, wurden die Reports bei allen Projekten von Hand neu erstellt.

Ebenfalls nicht zu erklaeren waren bei zwei Projekten die Verwerfungen, die in der Reihenfolge der Druckausgabe auftraten. Auch die Microsoft-Hotline war machtlos. Erst eine gehoerige Portion experimentelle Informatik sowie ein vehementer Work around halfen schliesslich, das Problem zu loesen.

Selbstbeschraenkung erleichtert auch in diesem Fall die Umstellung: Mit der Verwendung beispielsweise von Courier als Schriftart vermeidet der Entwickler, dass nach einem erfolgreichen Einsatz des Migrationswerkzeugs die Spaltenausrichtung, die urspruenglich in Dbase durch muehevolles Auszaehlen der Zeichenanzahl erreicht wurde, nun in Foxpro zu flattern beginnt.