[1 ] [2 ] [3 ]

Programmieren mit Visual FoxPro

Die Datenbank

Eine xBase Datenbank, wie die von FoxPro 2.6, besteht aus Tabellen und den dazugehörenden Indexdateien. Einen Überbau, der die zusammengehörenden Tabellen zentral verwaltet, gibt es nicht. Der Entwickler muß in seinem Programm selbst dafür sorgen, daß Beziehungen geknüpft werden, neue Tabellensätze mit Standardwerten versorgt werden und daß zum Beispiel keine Lagerartikel gelöscht werden können, für die noch Bestellungen vorliegen. Eine solche zentrale Verwaltungsinstanz für die Tabellen einer Datenbank stellt Visual FoxPro nun mit dem DBC zur Verfügung. Die Abkürzung DBC steht für DataBase Container. Der DBC ist selbst eine xBase-Tabelle, in der alle die Angaben gespeichert werden, die im Tabellen- oder Index-Header nicht untergebracht werden können. Die einfachste Art, einen leeren DBC zu erzeugen, ist, im Projektmanager von Visual FoxPro auf der Seite "Daten" die Zeile "Datenbanken" zu aktivieren und dann den "Neu" Knopf anzuklicken. Den daraufhin erscheinenden Datenbankdesigner erreichen Sie auch, indem Sie mit CREATE DATABASE einen leeren DBC erzeugen und diesen anschließend mit MODIFY DATABASE zur Bearbeitung aufrufen. Ein Klick mit der rechten Maustaste innerhalb des noch leeren Datenbankdesigners bringt ein Kontextmenü auf den Bildschirm. Der Menüpunkt "Neue Tabelle ..." bringt uns dann in den Tabellendesigner.

Abbildung 1: der Tabellendesigner von Visual FoxPro

Ein Blick auf den Tabellendesigner zeigt alle Neuerungen, die Visual FoxPro beim Erstellen von Datenbanktabellen zu bieten hat, konzentriert auf. Zunächst fällt auf, daß ein Tabellenname vergeben werden kann, der unabhängig vom Dateinamen dieser Tabelle ist. Wenn die Tabelle geöffnet wird, so wird der Tabellenname als Aliasname benutzt. Ein Tabellenname kann maximal 128 Zeichen lang sein, was auch der fleißigste Tipper selten ausschöpfen wird. Diverse Eigenschaften der Tabelle wie auch einzelner Felder können vorgegeben werden und werden im DBC festgehalten.

Bevor wir jedoch zu diesen Eigenschaften kommen, lassen Sie uns einen Blick auf die Definition der Felder werfen. Feldnamen können jetzt ebenfalls 128 Zeichen lang sein. Visual FoxPro kennt einige neue Feldtypen, zum Beispiel binäre Zeichen- und Memofelder, die von der automatischen Codepage-Umsetzung ausgenommen sind, einen Feldtyp Datum/Zeit, der für Felder gewählt werden kann, die als Zeitstempel dienen, die numerischen Feldtypen Double und Integer sowie den Feldtyp Währung.

  • Die binären Zeichen- und Memofelder können zum Speichern von Strings genutzt werden, die keine Textstrings sind, also beim Umsetzen der Tabelle auf eine andere Codepage unverändert bleiben sollen. Sie bieten sich zum Speichern von verschlüsselten Paßwörtern, Hexadezimalwerten oder Codeteilen bzw. Ausdrücken an, die mit EVALUATE() ausgewertet werden sollen.
  • Der Feldtyp Datum/Zeit belegt genau wie ein Datum 8 Bytes. Sie können mit Feldern dieses Typs auch die gleichen Rechenoperationen durchführen, wie mit Feldern vom Typ Datum. Zu beachten ist lediglich, daß Datum/Zeit-Felder mit Sekunden rechnen, während die kleinste Einheit bei reinen Datumsfeldern nach wie vor der Tag ist. So ergibt zum Beispiel {14.04.96 22:10:13} - 1 den Datum/Zeit-Wert {14.04.96 22:10:12} während {14.04.96} - 1 den Datumswert {13.04.96} ergibt.
  • Für Tabellenfelder, die zu Rechenoperationen benötigt werden, sind die Feldtypen Double und Integer dem schon von FoxPro 2.6 bekannten Feldtyp Numerisch vorzuziehen. Während Felder vom Typ Numerisch vor der Rechenoperation intern umgewandelt werden, ist dies bei Feldern vom Typ Double oder Integer nicht mehr nötig.
  • Der Feldtyp Währung belegt wie ein Double-Feld 8 Bytes und hat ein festes Format mit 15 Vor- und 4 Nachkommastellen.

.NULL.

Visual FoxPro stellt eine neue Konstante zur Verfügung, die .NULL. Dies hat sich auch in der Felddefinition niedergeschlagen. Hier können Sie nämlich angeben, ob ein Feld einen .NULL.-Wert annehmen kann oder nicht. .NULL. bedeutet - es ist kein Wert vorhanden, unterscheidet sich also von einer 0 in einem numerischen Feld oder von einem Leerzeichen in einem Textfeld. Selbst ein Leerstring ist nicht gleich .NULL. sondern immer noch ein String. Durch die Verwendung von .NULL. können Sie abprüfen, ob zum Beispiel eine Preisangabe explizit auf 0 gesetzt wurde oder ob der Anwender einfach vergessen hat, den Preis einzugeben - also kein Wert vorhanden ist. .NULL. besitzt keinen Typ. Wenn Sie nach einer Zuweisung wie LEER = {} abfragen: ? type('LEER') so erhalten Sie die Ausgabe "D" wie Datum, nach der Zuweisung LEER = .NULL. ergibt die Abfrage: ? type ('LEER') immer noch "D" - der einmal eingestellte Feldtyp bleibt also erhalten.

Ein Vergleich zweier Werte, von denen der eine .NULL. ist, liefert immer .NULL. als Ergebnis. Da einer der Vergleichswerte einfach nicht vorhanden ist, kann auch kein Ergebnis des Vergleichs vorhanden sein - eigentlich logisch. Leider wird diese Logik nicht ganz konsequent beibehalten. So liefern EMPTY(LEER) und ISBLANK(LEER) den Wert .F., wenn LEER gleich .NULL. ist. Zum Test auf einen .NULL.-Wert sollten Sie die Funktion ISNULL() benutzen. Diese Funktion ist dann besonders wichtig, wenn Sie in Ihrer Tabelle Felder mitführen, die .NULL. sein können. Sätze mit .NULL.-Werten kann man nämlich nicht über LOCATE FOR <Feldname> = .NULL. finden. Auch der Vergleich, den der LOCATE-Befehl mit den Feldern der Tabelle durchführt, liefert .NULL. zurück, wenn einer der Vergleichswerte - in unserem Fall die Vergleichskonstante - .NULL. ist. Die richtige Konstruktion muß also lauten LOCATE FOR ISNULL(<Feldname>).

Feldeigenschaften

Jedem Feld einer DBC-gebundenen Tabelle in Visual FoxPro können Sie vier Eigenschaften und einen Kommentar mitgeben. Im einzelnen sind dies:

  • Gültigkeitsregel: Hier können Sie eine Regel in Form eines Ausdrucks hinterlegen, der angibt, wie der im Tabellenfeld eingetragene Wert auf Gültigkeit überprüft werden soll. Der Ausdruck muß einen Wert .T. oder .F. zurückliefern. Wenn ein Tabellenfeld zum Beispiel nur Datumswerte enthalten soll, die größer oder gleich dem aktuellen Systemdatum sind, könnten Sie dies über den Ausdruck <Feldname> >= date() abprüfen. Statt <Feldname> muß dabei natürlich der aktuelle Feldname angegeben werden. Komplexere Abprüfungen können auch in eigenen Funktionen durchgeführt werden, die bei Gültigkeit des abzuprüfenden Wertes ein .T. zurückliefern und ein .F., wenn der Wert im Tabellenfeld nicht gültig ist. Solche Funktionen werden am besten direkt in der Datenbank gespeichert (siehe "gespeicherte Prozeduren" weiter unten).
    Die Gültigkeitsregel wird sofort überprüft, sobald der Anwender das mit dem Tabellenfeld verbundene Eingabefeld verlassen will. Dies ist unabhängig von der Art der Pufferung (die verschiedenen Möglichkeiten der Pufferung beschreibe ich ebenfalls weiter unten) und gilt sowohl für Eingabemasken als auch für den BROWSE-Befehl. Durch das Festlegen von Gültigkeitsregeln auf Feld- oder Satzebene kann damit auch verhindert werden, daß über BROWSE oder durch andere Programme, die über ODBC auf die Tabelle zugreifen, nichtgültige Werte in ein Tabellenfeld geschrieben werden. Wenn Sie eine Gültigkeitsregel für ein Feld später nachtragen, so müssen alle bereits in der Tabelle gespeicherten Sätze dieser Regel entsprechen. Visual FoxPro prüft dies vor dem Speichern Ihrer neuen Regel ab und weigert sich, diese Regel zu speichern, wenn die Tabelle bereits Sätze enthält, die die Regel verletzen.
  • Gültigkeitstext: Hier kann ein Text hinterlegt werden, der ausgegeben wird, wenn der Eintrag in einem Tabellenfeld die zugehörige Gültigkeitsregel verletzt.
  • Standardwert: Diese Eigenschaft gibt an, welcher Wert bei einem APPEND BLANK in das Tabellenfeld eingetragen werden soll. Auch der INSERT-SQL Befehl trägt die Standardwerte in alle Tabellenfelder ein, die im Befehl nicht aufgeführt sind. Die Angabe eines Standardwertes ist immer dann wichtig, wenn Sie für das Feld eine Gültigkeitsregel angegeben haben, die leere Feldinhalte ausschließt. Ohne einen Standardwert, der der Gültigkeitsregel entspricht, könnten Sie sonst den Befehl APPEND BLANK nicht mehr nutzen, da dieser sich weigert, einen Satz an die Tabelle anzuhängen, wenn ein Feld des Satzes seine Gültigkeitsregel verletzt.
  • Überschrift: Die hier eingetragene Bezeichnung des Feldes wird unter anderem vom BROWSE-Befehl als Spaltenüberschrift benutzt. Die Formularassistenten von Visual FoxPro tragen diese Bezeichnung als Feldlabel in das Ein-/Ausgabeformular ein. Allerdings werden diese Label als Text, das heißt fest verdrahtet, im Formular eingetragen. Die Änderung einer Feldbezeichnung im Datenbankdesigner wirkt sich also nicht auf einmal erstellte Formulare aus. Wenn Sie das besser machen wollen als die Formularassistenten, so können Sie während des Ladevorgangs eines Formulars die aktuellen Feldbezeichnungen mit Hilfe des DBGETPROP-Befehls aus dem DBC auslesen und somit die Label Ihres Formulars aktualisieren. Aber hier greife ich vor - zurück zu den Feldeigenschaften.
  • Kommentar: Eigentlich keine Feldeigenschaft, aber immer sehr nützlich. Da Sie den Inhalt des Feldkommentars mit dem DBGETPROP-Befehl zur Laufzeit sowohl lesen als auch mit DBSETPROP verändern können, läßt sich der Feldkommentar auch für beliebige andere Zwecke verwenden.

[1 ] [2 ] [3 ]