Diese Session zeigt auf, wie mit der Entwicklungsumgebung Visual Extend der Firma Devigus Engineering AG Client Server Lösungen implementiert werden können. Es werden allgemeine Strategien beim Erstellen von Client Server Anwendungen behandelt, auf spezifische Client/Server Probleme eingegangen und Upsize Strategien von Fileserver zu Client Server Anwendungen vorgestellt.
Siehe hierzu die Session Notes zu Rapid Application Developmment mit Visual Extend in diesem Ordner.
File Server Anwendungen unterscheiden sich grundsätzlicher Art von Client Server Daten. Während bei Fileserver Anwendungen die Frage welche Daten dem Benutzer in einer Maske in einem Auswahlset zur Verfügung gestellt werden von untergeordneter Bedeutung ist ist diese Frage bei einer C/S Anwendung von entscheidender Bedeutung. Somit ändern sich natürlicherweise auch die Konzepte, wie dem Benutzer Daten zur Auswahl vorgestellt werden, grundsätzlich. Die Vorstellung, eine Fileserver Anwendung eins zu eins auf eine C/S Anwendung portieren zu können ist illusorisch wenn nicht bereits bei der Konzeption der Software auf die Datenselektionproblematika eingegangen wurde. Achtung: Es gibt in der Praxis laut Zeitungsberichten und unabhängigen Markterhebungen mehr misserfolgte C/S Projekte als erfolgreiche. Deshalb lohnt es sich auf jeden Fall den Weg zu einer C/S Lösung sorgfältig zu evaluieren und ggf. zu planen.
Faustregel: Erst ab 50 und mehr gleichzeitig arbeitenden Benutzern und bei mässig leistungsfähiger Client Hardware sowie suboptimalen Netzwerkkarten bezahlt sich eine C/S Lösung in Punkto Verarbeitungs-geschwindigkeit wirklich aus. Doch Achtung: Verarbeitungsgeschwindigkeit ist auf gar keinen Fall das alleinige Entscheidungskriterium bezüglich F/S oder C/S.
Jet Datenbanken können maximal 1,2 GB, Visual FoxPro Datenbanken maximal 2 GB, SQL Server Datenbanken maximal 200 GB Daten aufnehmen.
In SQL Server werden grundsätzlich alle Transaktionen protokolliert. Falls das System abstürzt kann auf diese Weise sichergestellt werden, dass keine Daten verloren gehen. Bei C/S Anwendungen besteht grundsätzlich zwar die Möglichkeit Transaktionen zu definieren, doch besteht immer noch die Möglichkeit, dass bei Systemabstürzen Dateien beschädigt werden.
Falls Ihre Anwendung rund um die Uhr laufen muss, haben Sie kaum eine andere Wahl als C/S. SQL Server erlaubt Daten zu sichern währenddem gearbeitet wird. Zusätzlich erlaubt SQL Server das Sichern von Transaktionen. Bei F/S Anwendungen müssen für solche Operationen grundsätzlich alle Benutzer das System verlassen.
SQL Server und Jet haben eingebaute Sicherheitsfunktionen während Visual FoxPro keine eingebauten Sicherheitsfunktionen kennt. Diese müssen separat implementiert werden.
Falls Sie grosse Datenbestände replizieren müssen bietet der SQL Server eine erhöhte Leistung als Visual FoxPro in einer F/S Umgebung. Zur Daten Replikation kann in Visual FoxPro auch mit Offline Views gearbeitet werden, ein mächtiges Instrument um Daten welche upzudaten sind zu replizieren und beim Wiederanschluss an die Hauptdatenbank automatisch updaten.
Für das logischen Design benötigen Sie für eine F/S und eine C/S Lösung dieselbe Zeit. Die physische Implementation einer SQL Server Datenbank ist jedoch wesentlich aufwendiger als die Implementierung einer Visual FoxPro Datenbank. Demnach kann die zur Verfügung stehende Zeit für die Implementierung durchaus ausschlaggebend sein ob eine C/S Lösung realisiert wrden kann oder nicht.
Feldlängen und Datentypen Änderungen können in der Visual FoxPro Datenbank problemlos vorgenommen werden. SQL Server erlaubt es nicht, Datentypen zu verändern oder Felder aus Tabellen zu verändern. Auch ist das Updaten von Strukturveränderungen bei C/S Systemen wesentlich aufwendiger als bei F/S Systemen wir Visual FoxPro oder Jet.
Denken Sie daran, dass Sie in einer C/S Lösung keine direkten SEEK befehle absetzen können. Stattdessen arbeiten Sie mit einer updatable View oder einem read only Cursor, welchen Sie zunächst indexieren müssen.
Auch gibt es keine direkten COPY TO oder APPEND FROM Möglichkeiten. Auch hier müssen Sie wieder über Views oder Cursors gehen.
Triggers und Stored Procedures müssen beim SQL Server in der “Server” SQL Syntax geschrieben werden. Sie können nicht wie bei Visual FoxPro Trigger und Stored Procedures Visual FoxPro Befehle bzw. Syntax verwenden.
Locking ist beim SQL Server wesentlich umständlicher als beim Visual FoxPro. Währenddem Visual FoxPro beim Sperren einzelner Datensätze anderen Benutzern immer noch das lesen erlaubt ist dies beim SQL Server nicht möglich. Auch wird beim Sperren beim SQL Server in vielen Fällen eine ganze Seite fon 2K gesperrt (sog. Page Locking), dies kann höchst unangenehme Folgen haben.
Die Performance Optimierung einzelner Queries kann beim SQL Server fein gesteuert werden. Bei Visual FoxPro ist dies kein Thema. Rushmore funktioniert automatisch , oder funktioniert nicht.
Visual Foxpro Queries sind auf eine Subquery pro Query begrenzt, nicht so SQL Server Queries welche via SQL Pass through auf den Server geschickt werden.
Um in Visual FoxPro Datensätze einer Tabelle hinzuzufügen ist einfach: use table, append from table2. Bei SQL Datenbanken muss das selbe wie folgt abgehandelt werden: insert into table1 select * from table2.
Um in Visual FoxPro Daten aus einer Tabelle in eine andere zu kopieren würde in Visual FoxPro typischerweise mit einem set relation to… und einem anschliessenden replace all … Befehl abgehandelt. Beim SQL Server wird dasselbe mit einem Update Befehl erledigt: update customer from table2 set table1.field1 = table2.field1 where table1.field1 = table2.field1.
Bei einem Mehrschichten Modell sind nicht nur zwei (client und server) sondern meistens drei (client, middleware, server) Schichten vorhanden. In diesem Fall werden in der Regel die Business Rules zwar auf demselben Server aber in einem separaten Prozess laufen und die Business Rules beinhalten. Auch denkbare Szenarien sind der Einsatz von OLE Servern, welche irgendwo im Server Netzwerk zur Verfügung stehen und bestimmte Funktionalitäten abdecken. Denkbar wäre z.B. das definitive Ausdrucken von Belegen wie z.B. Lieferscheinen und Fakturen mit allen damit verbundenen Logistik Transaktionen.
Visual Exted bietet eine Reihe von Features welche auf das Erstellen von C/S Anwendungen ausgelegt sind. Trotzdem bleiben eine Reihe von Konzeptionellen Punkten in den Händen des Entwicklers.
Visual Extend unterstützt den Entwickler beim Erstellen von C/S Systemen, falls Views zum Einsatz gelangen. Der einzige praktikable Weg eine F/S Lösung zu einer C/S Lösung upzusizen besteht darin bereits im F/S Umfeld mit local views zu arbeiten und diese anschliessend auf remote views upzusizen. Hierzu bietet Visual FoxPro einen Upsize Wizard an.
Definieren Sie eine View, in welcher Sie die Parameter, welche für die Selektion der Daten erforderlich sind mit cQueryArg1, cQueryArg2, usw. verwenden. Für Views welche keine Selektion besitzt lassen Sie dies entsprechend weg. Doch aufgepasst: Falls Ihre Tabelle gross ist, ist es auf jeden Fall angebracht, mit Abfrageparametern die runtergeladenen Daten zu beschränken.
Erstellen Sie mit den Visual Extend Buildern (oder, falls Sie Zeit und Lust haben auch manuell) Ihr Form. Setzen Sie die Form Property lWorkOnView auf true. Diese Eigenschaft definiert, dass mit Views gearbeitet wird und entsprechend die Requery() Methode des Forms sowie die Form Property cQueryArg berücksichtigt werden. Denken Sie auch daran, im Data Environment die Property NoDataOnLoad auf true zu setzen.
VFX generiert automatisch einen Selektionsscreen, welcher vollautomatisch aufgrund der Where Bedingung Ihrer View zur Laufzeit erstellt wird. Dieser Selektionsdialog berücksichtigt auch allfällige FixField Felder, d.h. Felder welche bei einem Child Formular fest definiert sind.
Nach diesem Aufruf wird die View neu aufgebaut und Sie sehen in Ihrem Formular die bezogenen Daten und können wie gewohnt weiterarbeiten. Eine weitere VFX Property cQueryArgName definiert auf Eingabecontrol Ebene Ihres Forms wird dazu verwendet bei mehreren Parametern den richtigen Parameter mit dem entsprechenden Feld zu verknüpfen.
Diese Funktionalität deckt bereits vollumfänglich das Erstellen von standard Daten Formularen im C(S Umfeld ab.
Hier läuft alles was die Parent Tabelle betrifft grundsätzlich identisch zum oben beschriebenen standard Datenformular ab. Zusätzlich wird in der View für das Child Element eine Referenz zur Parent Tabelle definiert. Typischerweise mit Child.Feld=parent.Feld. Auf diese Weise kann nach der Selektion der Parent Query und einem Datensatzwechsel im Parent die Requery() Methode des Child Grids aufgerufen werden um somit jedesmal z.B. die Positionen des angewählten Auftrages anzuzeigen. VFX erledigt dies alles vollautomatisch.
Wir werden eine VFX Demo Anwendung erstellen, welche die Verwendung von Views im DataFormPage sowie im OneToMany Form aufzeigen. Diese Demo Anwendung wird auf unserer Homepage herunterladbar sein.