[1 ] [2 ] [3 ]

Bild 3: Der Verbindungsdesigner von Visual FoxPro

Entfernte Ansichten (Remote-Views) greifen über eine??? ODBC-Verbindungen auf eine andere Datenquelle zu. Zur Definition dieser Verbindungen bietet Visual FoxPro einen Verbindungsdesigner an. Dort werden Datenquelle, Benutzerkennung und Paßwort oder alternativ ein Connection String hinterlegt. Der Verbindungsdesigner ermöglicht darüber hinaus die Festlegung von Parametern, die die Verbindung steuern oder optimieren. So kann zwischen synchroner und asynchroner Verarbeitung gewählt werden, Warnmeldungen des Servers können ausgeblendet werden, der Batch-Modus entscheidet darüber, ob alle Ergebnisse eines gesendeten Statements, das mehrere SELECTs enthält, gemeinsam zurückgeliefert werden oder einzeln, sobald der erste Ergebniscursor verfügbar ist. Die Wahl "automatische Transaktionen" bewirkt, daß jedes gesendete SQL-Statement als eigene Transaktion aufgefaßt wird. Ohne automatische Transaktionen muß die auf dem Server mit dem ersten Befehl angestoßene Transaktion vom Programm selbst mit einem COMMIT oder ROLLBACK beendet werden. Bei der Erstellung eines Remote-Views können weitere Parameter angegeben werden, die die Performance beeinflussen. Dies ist zunächst die Anzahl der in einem Block abzurufenden Sätze (Fetch Size), die standardmäßig auf 100 eingestellt ist. Wenn 100 Sätze des Ergebnisses gefunden wurden, wird die Kontrolle an das Programm zurückgegeben, das diese ersten Sätze bereits anzeigen oder verarbeiten kann. Im Hintergrund wird der Ergebniscursor dabei mit weiteren Sätzen gefüllt. Die maximale Anzahl der zu übertragenden Sätze ist eine Sicherung, die eingesetzt werden sollte, solange Sie nicht ganz sicher sind, daß Ihr Programm an keiner Stelle ungewollt alle Sätze einer Tabelle aus der Serverdatenbank abruft. Da Serverdatenbanken im allgemeinen keine Memofelder à la xBase kennen, können Sie angeben, ab welcher Größe ein Feld als Memofeld betrachtet werden soll und ob Sie Memofelder eventuell getrennt abrufen wollen. Die Definition der Verbindungen und Ansichten werden??? im DBC gespeichert. Zur Laufzeit können Sie die eingestellten Werte mit DBGETPROP() auslesen und größtenteils auch mit DBSETPROP() neu setzen.

SQL Pass-Through

Neben dem View-Support ermöglicht Visual FoxPro den Zugriff auf Serverdatenbanken über die SQL Pass-Through-Technik. Mit SQLEXEC() kann jede gewünschte SQL-Anweisung an den Server abgeschickt werden. Das erlaubt einen direkten Zugriff auf einstellbare Servereigenschaften, Definition und Änderung von Tabellen auf dem Server und Zugriff auf gespeicherte Prozeduren des Servers. Ansichten und SQL Pass-Through können kombiniert werden. Zusammen mit der sehr schnellen, robusten Datenbankengine von Visual FoxPro machen sie Visual FoxPro zu einer äußerst leistungsfähigen Client/Server-Entwicklungsumgebung.

Gespeicherte Prozeduren

Im DBC werden nicht nur die erweiterten Definitionen für Tabellen und Felder, die benannten Verbindungen und die Definitionen der lokalen oder entfernten Ansichten abgelegt. Im DBC kann darüber hinaus jede benutzerdefinierte Prozedur oder Funktion hinterlegt werden, die immer dann zur Verfügung stehen muß, wenn die Datenbank geöffnet ist. Gespeicherte Prozeduren werden beim Öffnen der Datenbank automatisch in den Speicher geladen. Sie sollten sich deshalb auf Funktionen beschränken, die immer dann verfügbar sein müssen, wenn die Datenbank-Struktur oder die in der Datenbank gespeicherten Daten verändert werden. Dies trifft generell auf die Funktionen zu, die von den Ausdrücken aufgerufen werden, die die Gültigkeitsregeln für Tabellenfelder und Tabellensätze beschreiben. Die Funktionen, die von den UPDATE-, INSERT- und DELETE-Triggern aufgerufen werden, gehören ebenfalls als gespeicherte Prozeduren in die Datenbank. Verarbeitungsfunktionen Ihrer Anwendung sollten Sie jedoch nicht in der Datenbank speichern, da diese nur unnötig Hauptspeicherplatz belegen, wenn die Datenbank außerhalb Ihrer Anwendung geöffnet wird.

Pufferung, Satzsperre und Tabellensperrung

Wenn Sie in FoxPro 2.x ein Feld einer Datentabelle direkt mit einem Ein-/Ausgabefeld einer Maske verknüpft haben, mußten Sie selbst dafür sorgen, daß der Inhalt des Datensatzes vor dem Ändern gesichert wurde, um dem Anwender die Möglichkeit zu geben, seine Änderungen rückgängig zu machen. Die weitaus meisten FoxPro-Programmierer haben deshalb darauf verzichtet, direkt auf den Tabellen der Datenbank zu arbeiten. Stattdessen wurde mit Hilfe des SCATTER-Befehls der Inhalt des Datensatzes in Speichervariablen übertragen, die nach der Änderung mit GATHER zurück in den Datensatz geschrieben wurden. Diese Vorgehensweise hat sich nun erübrigt, da Visual FoxPro unterschiedliche Möglichkeiten der Pufferung anbietet. Die Felder einer gepufferten Tabelle können jetzt problemlos mit Ein-/Ausgabefeldern verknüpft werden. Jede Änderung, die der Anwender an den Daten vornimmt, landet nämlich zunächst im VFP-eigenen Puffer für diese Tabelle. Erst wenn über das Programm (oder das Befehlsfenster) der Befehl TABLEUPDATE() aufgerufen wird, werden die Daten in die Originaltabelle zurückgeschrieben. TABLEREVERT() verwirft alle Änderungen und aktualisiert den Puffer wieder mit den Originaldaten. Für jede Tabelle können Sie folgende Auswahl treffen:

1. Keine Pufferung: Verhalten wie bisher unter FoxPro 2.x
2. Pessimistische Datensatzsperre: Der Originaldatensatz wird gesperrt, bevor er in den Puffer übertragen wird. Dort kann er bearbeitet werden, ohne daß die Gefahr besteht, daß gleichzeitig ein anderer Benutzer Änderungen an diesem Datensatz vornimmt. Die Sperre erfolgt, sobald der Anwender beginnt, den Datensatz zu ändern. Wenn der Satz nicht gesperrt werden kann, gibt Visual FoxPro einen Hinweis aus. Ist der Satz gesperrt, können andere Anwender nach wie vor lesend darauf zugreifen. Sie erhalten jedoch immer die Daten im Ursprungszustand, das heißt ohne die Änderungen, die gerade an diesem Datensatz vorgenommen werden.
3. Optimistische Datensatzsperre: In diesem Fall wird der Originaldatensatz sofort in den Puffer geladen und kann dort verändert werden. Die Sperre erfolgt erst beim Speichern der geänderten Daten. Dadurch können Aktualisierungskonflikte entstehen, die durch eine Fehlerbehandlungsroutine abgehandelt werden müssen. Mit GETFLDSTATE() läßt sich feststellen, ob und welche Feldwerte zwischenzeitlich verändert wurden und ob der Löschstatus des Satzes während der eigenen Bearbeitung verändert wurde. CURVAL() gibt den aktuellen Wert eines Feldes im Originaldatensatz an, während OLDVAL() den Wert des Feldes angibt, den es vor der eigenen Änderung hatte. Mit diesen Abfragen können Sie entscheiden, wie auf den Aktualisierungskonflikt zu reagieren ist. Abhängig von dieser Entscheidung können Sie die Aktualisierung entweder durch Setzen eines Zusatzparameters bei TABLEUPDATE() erzwingen oder Ihre eigenen Änderungen durch TABLEREVERT() verwerfen.
4. Pessimistische Tabellensperrung: Jeder Datensatz wird gesperrt, sobald er bearbeitet wird. Wenn der Satzzeiger auf einen anderen Satz verschoben wird, wird im Gegensatz zur pessimistischen Datensatzsperre keine Aktualisierung der Originaldaten vorgenommen. Der Satz bleibt weiterhin gesperrt, bis mit einem TABLEUPDATE() alle bearbeiteten Sätze aktualisiert werden.
5. Optimistische Tabellensperrung: Alle bearbeiteten Sätze bleiben im Puffer, bis mit einem TABLEUPDATE() die Aktualisierung versucht wird. Auch hierbei kann es zu Aktualisierungskonflikten kommen, wenn einer der Sätze zwischenzeitlich von einem anderen Benutzer verändert wurde. Die Aktualisierung wird durchgeführt, bis alle Sätze aktualisiert sind oder ein Aktualisierungskonflikt aufgetreten ist. Ein Aktualisierungskonflikt sollte auch hier mit einer entsprechenden Fehlerroutine behandelt werden. Mit der Funktion GETNEXTMODIFIED() können Sie vor der Aktualisierung prüfen, ob irgendwo ein Konflikt auftreten würde, und diesen im Vorhinein abhandeln.

Transaktionen

Wenn während der Aktualisierung mehrerer Sätze ein Konflikt oder ein anderer Fehler auftritt, so sind die Originaldaten der vorher aktualisierten Sätze bereits geändert. Gesetzt den Fall, Ihre Fehlerbehandlungsroutine ermöglicht dem Anwender den Abbruch des Aktualisierungslaufs oder kann aus anderen Gründen den Konflikt nicht lösen und die Aktualisierung fortsetzen, so enthält Ihre Datenbank im schlimmsten Fall einen inkonstistenten Datenbestand. Um das zu vermeiden, können Sie Ihre Aktualisierungsoperationen als Ganzes schützen, indem Sie diese als eine Transaktion durchführen. Dazu setzen Sie vor die Aktualisierungsoperationen den Befehl BEGIN TRANSACTION und schließen die Aktualisierungsoperationen mit einem END TRANSACTION ab. Wenn nun zwischendurch ein nicht behebbarer Fehler auftritt, können Sie alle bis dahin vorgenommenen Änderungen mit ROLLBACK rückgängig machen. Da Datenbankserver eigene Transaktionsschutzmechanismen haben, gelten diese Befehle nur für FoxPro-eigene Tabellen. Im Umgang mit Datenbankservern können Sie entweder die automatischen Transaktionen verwenden (siehe dazu weiter oben "Client/Server Programmierung) oder mit SQLCOMMIT(), dem Pendant zu END TRANSACTION, die mit dem ersten SQL-Statement begonnene Transaktion abschließen. SQLROLLBACK() macht auch hier alle bis zu dem aufgetretenen Fehler durchgeführten Aktualisierungen wieder rückgängig.

Wie geht's weiter?

In der nächsten Ausgabe??? werden wir die zweite große Hürde angehen, mit der Visual FoxPro die xBase-Gemeinde konfrontiert hat: die objektorientierte Programmierung. Ich möchte Ihnen zeigen, wie die Konzepte der objektorientierten Programmierung in Visual FoxPro verwirklicht wurden und welchen Nutzen Sie als Anwendungsentwickler daraus ziehen können.

[1 ] [2 ] [3 ]