Seit der Einführung von Visual Foxpro 1995 gibt es auch lokale und Remote-Views. Doch bis zum heutigen Zeitpunkt werden diese Features relativ wenig genutzt. Dabei ermöglichen gerade diese eine bedeutende Erleichterung der Anwendungsentwicklung. Diese Session erläutert Ihnen die Grundlagen von lokalen und Remote Views, zeigt Ihnen die Vorteile dieser Technologie auf. Desweiteren werden die Unterschiede zwischen Remote-Views und SQL-Passthrough dargestellt.
Unter Client/Server versteht man einen Kommunikationsmechanismus, bei dem Anfragen von einem Client an einen Server gestellt werden. Diese Anfragen werden vom Server interpretiert, verarbeitet und deren Resultat an den Anfragenden zurückgegeben. Üblicherweise besteht der Client aus einer Anwendung, die Daten abfragt oder zur Speicherung übergibt, während die Server-Anwendung ein Relationales Datenbanksystem ist.
Durch diesen Mechanismus wird die Arbeit zwischen den Anwendungen verteilt. Außerdem werden im Vergleich zu reinen File-Server-Datenbanken die Netzwerkressourcen geschont, weil die Daten selektiert werden, bevor sie transportiert werden.
Der größte Vorteil von Client/Server-Anwendungen liegt sicherlich in ihrer Skalierbarkeit. Wenn die Ansprüche an das Datenbanksystem wachsen, muß man nur das Back-End erweitern, bzw. auswechseln oder mit neuer Hardware versehen, und schon profitieren alle Anwendungen und deren Benutzer davon. Die Verwendung verteilter Datenbanken ist nur durch Client/Server-Technologie möglich. Verteilte Datenbanken sind zwar schon seit einigen Jahren ein Thema, doch sie gewinnen mit der heutzutage üblichen Globalisierung - nicht zuletzt durch Verwendung von INTRANET / INTERNET - erst jetzt richtig an Bedeutung. Nicht vergessen sollte man auch die hohe Fehlertoleranz, bzw. Sicherheit von Client/Server-Datenbanken, die schon durch eigene Mechanismen vor Inkonsistenzen und unerlaubten Zugriffen schützen, ohne daß der Anwendungsprogrammierer sich damit beschäftigen muß.
Mit Visual Foxpro können Sie die Vorteile von Client/Server-Datenbanken nutzen, ohne auf die hohe Geschwindigkeit der VFP-Engine verzichten zu müssen. Dies erfordert zwar zunächst einiges Umdenken für hard-headed FoxPro Profis, weil wir uns hier mit mengenbasierten Datenzugriffen beschäftigen und einige der guten alten Navigationstechniken über Bord werfen müssen. Dafür haben Sie aber ein mächtiges Werkzeug in der Hand, um relativ datenbankunabhängig und unter Schonung der Netzwerkressourcen flexibel agieren zu können.
Wir haben mit Visual Foxpro grundsätzlich zwei Möglichkeiten, mit Client/Server-Datenbanken zu kommunizieren: Über Views und SQL Pass-Through. Im Folgenden werden wir hier die Zugriffsmöglichkeiten darstellen und erläutern, warum es auch sinnvoll ist, mit einer VFP-Datenbank die C/S-Techniken zu nutzen.
Ein View ist eine Datenansicht, die in der Datenbank gespeichert ist. Diese Persistenz in der Datenbank ermöglicht es, immer wieder auf Views zugreifen zu können, ohne sie jedesmal neu definieren zu müssen. In VFP-Programmen können Views einfach wie Tabellen einer Datenbank mit USE geöffnet werden, sobald die Datenbank selbst geöffnet wurde. Zusätzlich zu den reinen Ansichtseigenschaften (WAS soll angezeigt werden, WOHER stammen die Informationen) enthält eine Viewdefinition Informationen über die Updatefähigkeit, bzw. Art des Updates des Views und seiner einzelnen Felder.
Ich weiß. Einige von Ihnen haben es vielleicht schon immer befürchtet, bisher die Notwendigkeit weit von sich gewiesen, auf altbewährtes vertraut, weil doch gerade die schnellen Datenbankroutinen der große Vorteil von FoxPro sein sollen, und weil es eben doch so bequem ist. Stellen Sie sich der Herausforderung in dem Wissen, daß die FoxPro-Engine nicht ausgebremst wird: Nutzen Sie Views! Warum?
Grundsätzlich haben Sie drei Möglichkeiten, einen View zu erstellen: Entweder Sie nutzen den VFP-View-Designer, oder Sie erstellen den View manuell in der Entwicklungsumgebung oder programmatisch in Ihrer Anwendung. Auf den View-Designer soll hier wegen seiner einfachen Bedienbarkeit nicht weiter eingegangen werden. Die manuelle/programmatische Erstellung von Views erfordert die Ausführung eines CREATE SQL VIEW - Befehls.
Wir erstellen hier beispielhaft einen View, der über eine parametrisierte Bedingung auf eine Tabelle zugreift. Die Syntax ist hier der Vollständigkeit halber kurz aufgezeigt, für genaue Informationen nehmen Sie bitte Einblick in das Handbuch, bzw. die Online-Hilfe von VFP.
CREATE SQL VIEW vkunden [...weitere Parameter...] ; AS SELECT kunden.* ; FROM kunden WHERE kunden.land = ?lcCountry
Um die Einbindung von Views in VFP-Programme verstehen zu können, müssen wir uns zunächst im klaren darüber sein, was passiert, wenn ein View benutzt wird. Die Darstellung ist an dieser Stelle beispielhaft für lokale Views, im Kapitel Remote Views sind die Unterschiede dargestellt.
Wie schon oben gesagt, ist ein View eigentlich nichts anderes als eine Definition, die sich in der Datenbank befindet. Wenn nun ein View geöffnet wird (mit USE oder über die Datenumgebung einer Form), erstellt VFP einen temporären Cursor, dessen Alias denselben Namen trägt wie der View, der geöffnet wurde. Man arbeitet also nicht direkt auf dem View, sondern auf einer temporären Tabelle, die das Ergebnis der Abfrage enthält.
Das Verständnis für diesen Umstand ist besonders dann wichtig, wenn man Eigenschaften des Views/Cursors ändern möchte, oder wenn man bestimmte Daten aus dem View selektieren möchte. Wenn man nämlich ein Feld über ALIAS.FELDNAME anspricht, so erhält man den Inhalt des Cursors (also im Zweifelsfalle den gerade vom Benutzer geänderten Wert). Wenn man aber einen SQL SELECT auf dem View durchführt, so steht dort noch der alte Wert, solange der Puffer nicht weggeschrieben wird.
Eigenschafen des Views werden durch die Funktionen DBGETPROP() / DBSETPROP() aus der Datenbank gelesen / in die Datenbank geschrieben. Eigenschaften des Cursors werden durch die Funktionen CURSORGETPROP() / CURSORSETPROP() gelesen / temporär für diesen festgelegt.
Nichts leichter als das. Sobald Sie einen View erstellt haben, können Sie diesen in einer Form (=Formular, Maske) benutzen. Fügen Sie den View der Datenumgebung der Form hinzu, und schon können Sie die Control-Sourcen der Form-Controls mit View-Feldern verknüpfen. Um das Öffnen und Schließen des Views brauchen Sie sich nicht zu kümmern, das übernimmt die Datenumgebung der Form für Sie.
Was Sie beachten sollten:
Setzen Sie die NoDataOnLoad-Eigenschaft des Cursors auf .T., wenn Sie die Form zunächst ohne Daten laden wollen. Sie können so bei oder nach dem Laden der Form die View-Parameter (siehe Parametrisierung) ermitteln und erst bei Bedarf auf genau die Datenmenge zugreifen, die benötigt wird.
Den View erneut abfragen können Sie über die Funktion REQUERY(<alias>). Mit <alias> ist hier der Cursor des Views gemeint.
REQUERY() oder die Bewegung des Datensatzzeigers stoßen den Update-Mechanismus des Views an.
Wenn Sie mehrere Views in einer Form benutzen, schreiben Sie den Namen des Alias, der zuerst selektiert werden soll, in die InitialSelectedAlias-Eigenschaft der Datenumgebung.
Was im Absatz "Erstellen von Views" lapidar als "parametrisierte Bedingung" bezeichnet wurde, gewinnt bei der Benutzung von Views in der Anwendung an Bedeutung. Indem Sie nämlich in der WHERE-Klausel des Select-Statements eine Speichervariable angeben (im Beispiel lcCountry), können Sie zur Laufzeit der Anwendung bestimmen, welche Datensätze angezeigt werden sollen. Sie können den View mit NoDataOnLoad öffnen, die Bedingung ermitteln und dann die Daten mit REQUERY() abrufen (REFRESH der betroffenen Controls nicht vergessen!).
Um Daten über einen View aktualisieren zu können, müssen zusätzlich einige Eigenschaften des Views gesetzt werden. Auch dies können Sie entweder über den View-Designer erledigen, oder indem Sie die dafür notwendigen Funktionen aufrufen. Um die Eigenschaften mit der View-Definition in die Datenbank zu schreiben, benutzen Sie die DBSETPROP()-Funktion. Um die Eigenschaften bei geöffnetem View temporär in dessen Cursor zu schreiben, benutzen Sie die CURSORSETPROP()-Funktion. Die Benutzung dieser Funktionen entnehmen Sie bitte dem Handbuch.
Die zum Update benötigten View-Eigenschaften sind im Folgenden aufgelistet. Bitte beachten Sie, daß sämtliche Eigenschaften korrekt gefüllt sein müssen, damit das Update erfolgreich ist.
| Zweck | View-Eigenschaft (1) | Cursor-Eigenschaft (2) |
|---|---|---|
| Zulassen einer Tabelle zum Aktualisieren |
Tables |
Tables |
| Angeben der Remote-Namen der Felder einer Ansicht |
UpdateName (Eigenschaft auf Feldebene) |
UpdateNameList |
| Angeben der Felder einer Ansicht, die Sie als Schlüssel verwenden möchten |
KeyField (Eigenschaft auf Feldebene) |
KeyFieldList |
| Angeben der aktualisierbaren Felder einer Ansicht |
Updatable (Eigenschaft auf Feldebene) |
UpdatableFieldList |
| Aktivieren von Aktualisierungen |
SendUpdates |
SendUpdates |
Sie können einen geöffneten View wie eine normale Visual Foxpro - Tabelle behandeln. Sie haben hier also die Wahlmöglichkeit, ob Sie Datensätze mit SQL-Befehlen oder FoxPro-Befehlen bearbeiten. Der gute alte APPEND BLANK und REPLACE funktionieren wie gewohnt. Nur zum Schreiben der Daten in die Ursprungstabelle sollten sie noch etwas beachten. Natürlich könnten Sie einfach die Form schließen oder den Datensatzzeiger bewegen, um die Aktualisierung anzustoßen. Aber dann hätten Sie keine Kontrolle darüber, ob Ihre Änderungen tatsächlich in der Ursprungstabelle angekommen sind oder nicht. Also benutzen wir die Funktion TABLEUPDATE(), um das Update anzustoßen. TABLEUPDATE() gibt .T. oder .F. zurück, jenachdem, ob das Update erfolgreich war oder nicht.
Wenn Sie vergessen, die SendUpdates-Eigenschaft des Cursors/Views auf .T. zu setzen, ist TABLEUPDATE()=.T., obwohl das Update gar nicht gesendet wurde!
Wenn TABLEUPDATE() nicht erfolgreich war, können Sie den Fehler über AERROR() abfangen und auswerten. Fehlerquellen können zum Beispiel Verletzungen von Referentieller Integrität oder Aktualisierungskonflikte sein.
Wenn das TABLEUPDATE() nicht erfolgreich war und der Fehler nicht zu beheben ist, müssen Sie die Änderungen mit TABLEREVERT() wieder rückgängig machen.
Um mit Views arbeiten zu können, muß die Tabellen- oder Zeilenpufferung in VFP eingeschaltet sein. Grundsätzlich muß man dafür zunächst SET MULTILOCKS ON schalten. Views arbeiten standardmäßig mit optimistischer Zeilenpufferung, was bedeutet, daß die zu ändernde Zeile nur in dem Moment gesperrt wird, in dem sie weggeschrieben werden soll. Grids arbeiten grundsätzlich mit optimistischer Tabellenpufferung, so daß man nicht jeden Satz einzeln wegschreiben muß. In den allermeisten Fällen reicht das optimistische Pufferungsmodell aus, zumal Aktualisierungskonflikte von der Datenbank erkannt werden können.
Folgende Buffermodes sind für lokale Views möglich:
Wenn man mehrere Tabellen abhängig voneinander aktualisieren will, kann es sinnvoll sein, die Aktualisierung in eine Transaktion einzuschließen. Die Transaktion wird mit BEGIN TRANSACTION gestartet. Schlägt dann ein TABLEUPDATE() fehl, so kann man die bisher durchgeführten Änderungen durch ROLLBACK wieder rückgängig machen. Klappt alles, so beendet man die Transaktion durch END TRANSACTION. VFP unterstützt bis zu fünf Transaktionslevels, so daß man die Transaktionen auch schachteln kann.
Ähnlich wie der lokale View ist ein Remote View eine Ansichtsdefinition, die sich in einer VFP-Datenbank befindet. Wenn man sie öffnet, wird ebenfalls ein Cursor erstellt, auf dem man genauso arbeiten kann, als handle es sich um VFP-Daten. Der Unterschied besteht eigentlich nur darin, daß der Remote View nicht auf Daten aus einer Tabelle, die sich in einer VFP-Datenbank befindet, zugreift, sondern daß die Datenquelle grundsätzlich irgendeine relationale Datenbank sein kann. Auf diese Backend-Datenquelle wird von der Frontend-VFP-Anwendung über einen ODBC-Treiber als verbindende Middleware zugegriffen.
Die Arbeit mit Remote Views unterscheidet sich gar nicht so sehr von den lokalen Views. Wie Sie in der Abbildlung sehen, besteht für die VFP-Anwendung eigentlich gar kein Unterschied. Sie arbeitet weiterhin auf einem temporären Cursor, dessen Eigenschaften genauso gelesen, bzw. geschrieben werden können, als basiere dieser Cursor auf einem lokalen View. Lediglich die Viewdefinition in der VFP-Datenbank und die Herkunft der Daten unterscheiden sich etwas von den lokalen Views. Aber der Anwendung selbst kann das (fast) egal sein.
Die Besprechung des Upsizing-Assistenten würde hier den Rahmen sprengen. Sie können sein Funktionalität im Handbuch nachlesen oder ihn einfach ausprobieren. Mag er vielleicht ein noch so gutes Instrument zum Upsizing sein, wir wollen hier vor allem die grundsätzlichen Aspekte beleuchten, die Sie vor dem Upsizing, bzw. in der Planung der Datenbank beachten sollten.
Wenn Sie eine Datenbank planen, die entweder sofort oder später auf einem Client/Server Datenbanksystem liegen soll, so sollten Sie sich von Anfang an über die Möglichkeiten des Datenbanksystems informieren und stets den kleinsten gemeinsamen Nenner verfolgen. Die schönste durchgeplante VFP-Datenbank wird Ihnen keine Freude machen, wenn sie zum Beispiel auf Oracle 7 umgestellt werden soll und ihre Tabellen mehr als ein Memo-Feld oder logische Datenfelder enthalten. Wie gesagt, Information über das zukünftige Back-End ist alles und der kleinste gemeinsame Nenner gibt hier den Ton an.
Der ODBC-Treiber ist für uns das Tor zur Welt. Beachten Sie bitte, daß mit VFP zwar einige ODBC-Treiber mitgeliefert werden, daß aber die Originaltreiber der Datenbankhersteller meistens schneller und manchmal auch im Fehlerfall gesprächiger sind! Sie benötigen den installierten ODBC-Treiber und dazu einen eingerichteten DSN ("Data Source Name" oder "ODBC-Datenquelle"). Über diesen DSN wird die Verbindung zur Datenquelle hergestellt.
Connections sind Definitionen von benannten Verbindungen, die in der VFP-Datenbank gespeichert werden. Sie können Connections über den Verbindungsdesigner oder durch den Befehl CREATE CONNECTION erstellen. Der Name der Connection wird bei der Definition eines Remote View angegeben.
Beispielhaft haben wir hier eine Datentypen-Vergleichstabelle für den Microsoft-SQL-Server angegeben.
| SQL Server Type | Beschreibung | Domäne | Visual FoxPro Typ |
|---|---|---|---|
| binary(n) |
fixed-length binary |
1-255 bytes |
n/a |
| bit |
logical |
0 or 1 |
logical |
| char(n) |
fixed-length |
text 1-255 characters |
character |
| datetime |
dates & time accurate to the millisecond |
1/1/1753 to 12/31/9999 |
datetime |
| decimal |
exact numeric |
-10E38 to 10E38-1 |
n/a |
| float |
floating point |
1.7E-308 to 1.7E+308 |
numeric, float, double |
| image |
variable-length binary |
<= 2,147,483,647 bytes |
general |
| int |
integer |
-2,147,483,648 to 2,147,483,647 |
integer |
| money |
monetary |
-922,337,203,685,477.5808 to 922,337,203,685,477.5807 |
currency |
| numeric |
exact numeric |
-10E38 to 10E38-1 |
n/a |
| real |
floating point |
3.4e-38 to 3.4e+38 |
n/a |
| smalldatetime |
dates & time accurate to minutes |
1/1/1900 to 6/6/2079 |
n/a |
| smallint |
integer |
-32,768 to 32,767 |
n/a |
| smallmoney |
monetary |
-213,748.3648 to 214,748.3647 |
n/a |
| text |
variable-length text |
<= 2,147,483,647 characters |
memo |
| timestamp |
automatically updated varbinary |
(8) |
n/a |
| tinyint |
integer |
0 to 255 |
n/a |
| varbinary(n) |
variable-length binary |
1-255 bytes |
n/a |
| varchar() |
variable-length text 1-255 characters |
n/a |
Die Definition eines Remote-Views unterscheidet sich nur wenig von der eines lokalen Views. In unserem Beispiel sieht sie so aus:
CREATE SQL VIEW vkunden REMOTE; CONNECTION conn1 SHARE; AS SELECT kunden.* ; FROM kunden WHERE kunden.land = ?lcCountry
Wenn der View geöffnet wird, wird über benannte Verbindung conn1 eine Connection aktiviert. Unabhängig davon, ob mehrere Views dieselbe benannte Verbindung nutzen, kann entweder für jeden View eine neue Connection aktiviert werden oder eine Connection von mehreren Views genutzt werden. Dies ist vor allem dann von Interesse, wenn Client-Lizenzen über die Anzahl aktiver Connections abgerechnet werden (z.B. Oracle). Setzen Sie also in diesem Falle wie oben die ShareConnection Eigenschaft des Views.
| Remote Views benutzen nur bereits aktive Connections, wenn diese ebenfalls shared durch einen anderen remote View geöffnet wurden. Wenn Sie eine Connection mit SQL Pass-Through öffnen, wird diese nicht von Remote Views genutzt (außer bei Access). |
| Wenn Sie mit Shared Connections arbeiten, muß der Remote View stets (außer
bei Access) seine gesamte Ergebnismenge ziehen. Dafür müssen die View-Eigenschaften
MaxRecords und FetchSize auf -1 gesetzt werden! Ansonsten erhält man beim
Öffnen des Views die Fehlermeldung, daß die Verbindung belegt sei. Dies
widerspricht allen Regeln der Vernunft und steht in krassem Widerspruch
zu dem Bestreben, möglichst wenig Daten über die Leitung zu schicken. Laut Microsoft ist dieses Verhalten aber BY DESIGN. |
Im Prinzip ist ein geöffneter Remote View nichts weiter als ein Cursor mit Update-Eigenschaften. Deshalb kann er auch nicht automatisch die Remote-Datenbank sperren. Demzufolge stehen für remote Views nur die Buffermodes Optimistic Row und Optimistic Table zur Verfügung.
Standardmäßig werden Updates von remote View mit automatischen Transaktionen durchgeführt. Das bedeutet, daß jedes Update eines remote Views automatisch commited wird. Wenn man Updates mehrerer Views in Transaktionen einschließen möchte, muß man zunächst die Transactions-Eigenschaft der Verbindung auf manuell umstellen. Dann kann man die Transaktionen manuell steuern.
| Die BEGIN/END TRANSACTION - Befehle steuern nur die lokale VFP-Datenbank. Um auf der remote Server-Datenbank Transaktionen zu realisieren, muß man diese über SQL Pass-Through mit den Funktionen SQLCOMMIT() und SQLROLLBACK() steuern. |
SQL Pass-Through ist eine programmatische API für den direkten Zugriff auf Client/Server-Datenbanken. SPT kann nicht visuell generiert werden. Dafür kann man servereigene Syntax und Funktionen nutzen und hat jeden Zugriff selbst in der Hand.
Mit SQL Pass-Through kann man serverspezifische Elemente verwenden, wie z. B. gespeicherte Prozeduren sowie Funktionen, die nur der Server bereitstellt. Man kann neben den SQL-Erweiterungen, die der Server unterstützt, auch die Datendefinitions-, Serververwaltungs- und Sicherheitsbefehle verwenden. Mit SPT verfügt man über mehr Möglichkeiten zur Steuerung der Aktualisierungs-, Lösch- und Einfügebefehle. Außerdem kann man so Remote-Transaktionen steuern.
Hier die SQL Pass-Through Funktionen im Überblick:
| Aufgabe | Funktion | Zweck |
|---|---|---|
| Verwaltung von Verbindungen |
SQLCONNECT( ) |
Stellt eine Verbindung zu einer Datenquelle für SQL Pass-Through-Operationen her. |
| SQLSTRINGCONNECT( ) |
Stellt eine Verbindung zu einer Datenquelle unter Verwendung der Syntax für Verbindungszeichenfolgen her. |
|
| SQLDISCONNECT( ) |
Hebt eine Verbindung zu einer ODBC-Datenquelle auf, so daß die angegebene Verbindungskennung überflüssig wird. |
|
| Ausführung und Steuerung von SQL-Anweisungen |
SQLCANCEL( ) |
Bricht eine SQL-Abfrage ab, die asynchron über eine aktive Verbindung ausgeführt wird. |
| SQLEXEC( ) |
Führt eine SQL Pass-Through-Abfrage über eine aktive Verbindung aus; gibt die Anzahl der erstellten Ergebnismengen zurück oder 0, wenn die Ausführung von SQLEXEC ( ) noch andauert (asynchrone Verarbeitung). |
|
| SQLMORERESULTS( ) |
Legt eine weitere Ergebnismenge in einem Cursor ab. Gibt 0 zurück, wenn die Ausführung der Anweisung, welche die Ergebnismenge erstellt, noch andauert. |
|
| SQLPREPARE( ) |
Kompiliert die SQL-Anweisung in der Datenquelle vor und bindet die Visual FoxPro-Parameter. Dies bedeutet, daß die aktuellen Parameterausdrücke für alle Parameter in der SQL-Anweisung gespeichert werden. |
|
| SQLCOMMIT( ) |
Fordert die Übergabe einer Transaktion an. |
|
| SQLROLLBACK( ) |
Fordert das Zurücksetzen einer Transaktion an. |
|
| Datenquelleninformationen |
SQLCOLUMNS( ) |
Speichert eine Liste mit Spaltennamen und zugehörigen Informationen in einem Cursor. Gibt 1 bei erfolgreicher Ausführung der Funktion zurück oder 0, wenn die Ausführung noch andauert. |
| SQLTABLES( ) |
Speichert die Namen von Tabellen der Datenquelle in einem Cursor. Gibt 1 bei erfolgreicher Ausführung der Funktion zurück oder 0, wenn die Ausführung noch andauert. |
|
| Verschiedene Steuerungsmöglichkeiten |
SQLGETPROP( ) |
Erhält eine Verbindungseigenschaft von einer aktiven Verbindung. |
| SQLSETPROP( ) |
Legt eine Eigenschaft einer aktiven Verbindung fest. |
Bevor man über SQL Pass-Through auf den Server zugreifen kann, muß man eine Connection aktivieren. Dies geschieht entweder über eine benannte Verbindung, die in der VFP-Datenbank gespeichert ist (siehe Remote Views) oder direkt über die ODBC Datenquelle. Die Verbindung wird mit der SQLCONNECT()-Funktion geöffnet.
Wir verwenden hier die benannte Verbindung conn1 aus unserem Beispiel. SQLCONNECT() gibt bei Erfolg ein Handle auf die geöffnete Connection zurück, das bei der Ausführung weiterer Kommandos genutzt werden muß. Nun kann man zum Beispiel eine Abfrage ausführen:
In diesem Fall soll der Inhalt unserer Kundentabelle im Cursor ckunde zurückgegeben werden. Nach Ausführung der Kommandos sollte die Verbindung wieder mit getrennt werden:
Remote Views sind eine sehr effiziente und einfache Möglichkeit, mit Client/Server Datenbanken zu kommunizieren. Manchmal allerdings braucht man den direkten Zugriff auf die Datenbank, zum Beispiel zum generieren künstlicher Schlüssel oder zum Ausführen von Transaktionen. Dann hat man mit SQL Pass-Through ein flexibles Werkzeug an der Hand, um die gewünschten Zugriffe auszuführen.
Ein kleiner Wehrmutstropfen bleibt doch noch bei der Benutzung von SPT. Dadurch, daß es sich hierbei um ein spezifisches Werkzeug für den Client/Server Zugriff handelt, kann man ein Anwendungsprogramm bei seiner Benutzung nicht ohne weiteres auf unterschiedlichsten Datenbanken laufen lassen (also auch nicht auf einer lokalen VFP-Datenbank). Deshalb ist es nicht empfehlenswert, SQL Pass-Through direkt im Programm zu codieren. Vielmehr sollte man SQL Wrapper-Methoden benutzen, die die gewünschte Datenbasis erkennen und den Befehl entsprechend generieren können.
Dies war ein recht großzügiger Überblick über die Möglichkeiten von Views und remote Zugriffen. Wenn Sie weitergehende Informationen zu SQL Pass-Through benötigen, besuchen Sie die entsprechenden Sessions. Zum Thema SQL-Wrapper können Sie Kontakt mit den Tool-Herstellern aufnehmen, die diese anbieten. Einige Hersteller bieten auch die gesamte Steuerung von remote- und lokalen Zugriffen, was Ihnen viele graue Haare sparen dürfte.Für Fragen stehe ich Ihnen gerne unter Mengel@indisoftware.de zur Verfügung. Sie erreichen mich auch auf unserer Website www.indisoftware.de.