Client/Server mit Visual FoxPro 9.0 C/S Client/Server mit Visual FoxPro 9.0 deutschsprachige FoxPro User Group Uwe Habermann Microsoft Visual FoxPro 9.0 Roadshow

Die Idee Eine Anwendung soll so erstellt werden, dass beim Kunden entschieden werden kann, ob mit einer VFP-Datenbank oder mit einem SQL Server gearbeitet werden soll. Alle Formulare und Klassen müssen unabhängig von der Datenquelle sein.

Die Möglichkeiten Remote Views SPT (SQL Pass Through) CursorAdapter Basierend auf einer Connection im DBC gespeichert SPT (SQL Pass Through) Native Datenbank- oder ODBC-Syntax Beliebige Befehle/Scripts verarbeitbar (Fast) vollständige Kontrolle über Befehlsausführung Für „normale“ Anwendungsfälle eher umständlich Nichts für die einfache Portierbarkeit CursorAdapter

Remote Views vs. CursorAdapter Remote View und Connection im DBC gespeichert Nachteil: DBC muss verwendet werden Verbindungsinformationen im Klartext lesbar ggf. manipulierbar CursorAdapter als programmatische oder visuelle Klasse in die Exe-Datei eingebunden Zur Laufzeit beliebig konfigurierbar Mit DBC und Remote Datenbanken einsetzbar

Vorteile SQL Server Verfügbarkeit Datensicherheit Skalierbarkeit Clients haben keinen Einfluss auf die Serverdatenbank Wartungsaufgaben und Backup im laufenden Betrieb Datensicherheit Datenbank ist vor direktem Zugriff geschützt Security-Modell Skalierbarkeit

Nachteile SQL Server Betreuungsaufwand Lizenzkosten Qualifiziertes Betreuungspersonal notwendig Einzelne Tabellen können nicht kopiert oder ersetzt werden Lizenzkosten Oder kostenlos für den Einstieg: SQL Server Desktop Engine SQL Server 2005 Express Oder VAR-Vertrag mit Microsoft

Upsizing VFP Upsizing Wizard xCase (und andere Tools) Gute VFP-Unterstützung Möglichkeit zur Massenänderung (DBFs!)

Die Lösung CursorAdapter Vorteile: Klasse – Vererbung, Eigenschaften, Methoden Erstellter Cursor ähnlich Ansicht Einheitlicher Datenzugriff Datenzugriff auf DBC und SQL Server möglich Umschaltbarkeit zur Laufzeit Typkonvertierung möglich Builder in VFP vorhanden -> Beispiel 

Wie macht man es richtig? CursorAdapter-Klasse verwenden ConnectionManager ConnectionManager liest Datenbankinformationen aus Konfigurationsdatei Wichtig: CursorAdapter-Funktionalität unbedingt in einer Klasse speichern -> keine Änderung in der Datenumgebung von Formularen beim Wechsel der Datenquelle

Programmstart Im Init Ereignis des Anwendungsobjekts wird der ConnectionManager instanziiert Aus einer verschlüsselten Tabelle werden die Datenbankinformationen gelesen Beim Instanziieren eines CursorAdapters wird vom ConnectionManager eine Connection geholt Die CursorAdapter-Klasse verwendet die Informationen des ConnectionManagers (Der gezeigte Code kommt auf die Begleit-CD )

CursorAdapter Klasse Herstellen der Verbindung zur Datenbank über den ConnectionManager Holen von ID-Werten Wartbarkeit Eingriffsmöglichkeit an vielen Stellen BeforeUpdate, AfterUpdate

IDs IDs sollten von der Datenbank vergeben werden CursorAdapter ermöglichen diese IDs nach dem Speichern aus der Datenbank zu holen InsertCmdRefreshCmd – wird nach dem Insert ausgeführt – Hier können IDs geholt werden GETAUTOINCVALUE() bei DBC select * from <myTable> where <IdField>=GETAUTOINCVALUE() @@IDENTITY bei SQL Server

CursorAdapter Klasse Was ist neu? Maximale Länge eines Eigenschaftwerts bei Eingabe im Eigenschaftsfenster 8 KB Auto-Refresh-Unterstützung InsertCmdRefreshFieldList, InsertCmdRefreshCmd, InsertCmdRefreshKeyFieldList, UpdateCmdRefreshFieldList, …, RefreshTimestamp Erweiterte Refresh-Unterstützung RecordRefresh(), BeforeRecordRefresh(), … Verzögertes Abrufen von Memofeldern DelayedMemoFetch(), FetchMemoDataSource, … Transaktionen bei Update, Insert, Delete: neue Eigenschaft UseTransactions Besseres Konflikthandling ConflictCheckType / ConflictCheckCmd (VFP8 SP1) Neue Eigenschaft TimestampFieldList Lesen und Schreiben von hierarchischen XML Diverse Erweiterungen bzgl. ADO

Connection Manager Klasse Instanziierung ohne Datenanbindung Herstellen einer(!) Verbindung beim ersten Bedarf Auslesen der Datenbankinformationen aus einer Datei möglich Eine Connection für alle Datenzugriffe der Anwendung Verwendung mehrerer Datenbanken in einer Anwendung In einer Eigenschaft jedes CursorAdapters steht der zu verwendende Connection Manager

Planen einer neuen Anwendung Nur mit CusorAdapter Klasse arbeiten! Connection Manager verwenden Vorteile: Es wird nur 1 Verbindung benötigt Austauschbarkeit der Datenquelle Wechsel von DBC zu SQL möglich Entscheidung je Kunde ob DBC oder SQL verwendet werden soll

Ein Beispiel aus der Praxis VFP VFP? Venelina´ Fanstastic Pizzas 

VFPizza Customers.scx Erstellt mit dem VFX - Form Builder Steuerlemente zur Eingabe von Parametern hinzugefügt CursorAdapter mit dem CA Wizard erstellt SelectCmd um Where-Klausel erweitert

VFPizza Orders.scx 1:n Formular Erstellt mit dem VFX - Form Builder Steuerlement zur Eingabe von Parametern hinzugefügt CursorAdapter mit dem CA Wizard erstellt SelectCmd um Where-Klausel erweitert

Datenquellen bearbeiten Manage Config.vfx Verwaltung des Datenzugriffs Dialog in der Anwendung beim Kunden nutzbar Problemloser Wechsel zwischen DBC und SQL Server ConnectionString empfehlenswert Verschlüsselung mit Kennwort Einstellung mit dem Application Builder goprogram.cconfigpassword

Test Läuft die Anwendung mit DBC und SQL Server?

Vielen Dank! Uwe.Habermann@dFPUG.de Besuchen Sie unsere Webseiten: http://www.dfpug.de, http://portal.dfpug.de, http://forum.dfpug.de, http://newsletter.dfpug.de, http://devcon.dfpug.de, http://roadshow.dfpug.de, http://www.visualextend.de, http://www.linuxtransfer.de, http://www.visualfoxpro.de