[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]

Multi Remote View Ansatz

Wir nennen diesen Ansatz einen "Multi Remote View" Ansatz. Multi deshalb, weil mit beliebig vielen Remote Views in ein und demselben Form gearbeitet werden kann. Die VFX Klasse CAskViewArgPgf nimmt hier eine Schlüsselstelle ein. Im folgenden Beispiel wird die Verwendung der Klasse CAskViewArgPgf erläutert.

Wenn der benutzer ein Client/Server Form, welches mit dem "Multi Remote View" Ansatz implementiert wurde ögffnet, Sieht er sich zunächst mit einem Selektionsbildschirm konfrontiert.

In der oberen Combobox kann der Benutzer wählen, nach welcher Art er seine Daten beziehen will. Je nach Komplexität der Anwendung kann es hierbei durchaus meherer Seiten geben. Jeder angewählte Art entspricht intern einer bestimmten Seite und hat zur Folge, dass eine bestimmte View verwendet wird um die Daten zu beziehen. Das Geniale an diesem Ansatz ist, dass das Grundform dasselbe bleibt, und zur Laufzeit die benötigte Remote View ausgetauscht wird. Nachdem der Benutzer seine Selektionskriterien eingegeben hat, kann er die Daten im ganz normalen Datenmanipulations Bildschirm einsehen:

Im Unterschied zu anderen Client/Server Ansätzen, welche gar keine Navigationsmöglichkeiten und auch kein Grid besitzen, um aus dem Resultateset den gewünschten Datensatz auszuwählen, verfügt das VFX Framework auch im Client/Server Fall über alle Eigenschaften, welche bei einer Fileserver Anwendung so praktisch sind:

• Navigation
• Listendarstellung
• Inkrementelle Suche
• Sortierung sowie
• Filtrierung.

Somit liegt es in der Verantwortung des Benutzers, ob er mehrere Datensätze beziehen will um dann seine Suche mit den lokal zur Verfügung stehenden Datensätzen weiter zu verfeinern, oder ob er gleich zu Beginn die Daten soweit einschränkt, dass nur in einziger Datensatz über das Netz auf seine Arbeitsstation geladen wird.

Auch um andere Daten vom Server zu beziehen, ist in VFX bereits alles vorgesehen. Der Benutzer muss lediglich den "Abfrage…" Knopf in der entsprechenden Formtoolbar anwählen und schon befindet er sich wieder in dem eingangs gezeigten Selektionsbildschirm und kann dort erneut einen Datenbezug starten.

Ich werde in der Session die technische Implementation inkl. vollständiger, sehr detaillierter, deutschsprachiger Dokumentation an die Teilnehmer übergeben.

Mehrere Benutzer arbeiten mit demselben DBC

Wenn man in einem Mehrbenutzer Betrieb mit ein und demselben Datenbank Container arbeitet, ist es wichtig zu verstehen, dass die Informationen, welche zu den im DBC abgespeicherten Connections für alle Benutzer grundsätzlich die selben sind. Hat man eine Trusted Umgebung werden keine benutzerspezifischen Informationen in der Connection Definition abzuspeichern sein. Alle Benutzer können getrost mit ein und demselben DBC arbeiten.

Ist hingegen eine non trusted Umgebung vorhanden, d.h. einzelne Benutzer werden mit dem vom SQL Server selbst zur Verfügung gestellten Login Authentisierungsverfahren geprüft, ist es unabdingbar, dass im Connection String ein Username und Passwort mitgegeben wird. Ein Connection String bei non Trusted Umgebungen sieht wie folgt aus:
 

Wie man unschwer erkennen kann, steht Benutzername und Passwort im Connection String.

Obwohl es sehr praktisch ist, dass VFP alles im Zusammenhang mit einer Connection in einem DBC abspeichert, ist dies natürlich ein scheinbar unlösbares Problem wenn mehrere Benutzer mit ein und demselben DBC arbeiten. Es kann im DBC nur immer ein gültiger Connection String drinstehen.

Die Lösung ist genauso provokativ wie einfach: Wir propagieren ja, dass wir je Client Applikation jeweils eine shared Connection für alle Views verwenden soll. Dies ist in der vorgeschlagenen Lösung absolut prioritär einzuhalten. Der Ablauf ist folgender:

1. Beim Start der Applikation wird, bevor die erste Remote View geöffnet wird, der Eintrag im DBC richtiggestellt. Dies erfolgt proaktiv mit dem Befehl

dbsetprop("conXY", "CONNECTION", "ConnectString", lcConnectionString)

2. Selbst wenn mehrere Benutzer die Applikation gleichzeitig starten sollten, wird VFP das DBC kurzzeitig mit einem Lock sichern. Wir haben dbzgl. in der Praxis keine Probleme feststellen können.

   Beim Start der Applikation wird eine "dummy" remote view ohne Datenbezug geöffnet. Diese View bleibt bis ans Ende der Applikation offen

3. Da alle anderen Remote Views mit "share connection" versehen sind, wird nie mehr eine neue Connection aufgebaut und somit bleibt der Benutzer mit seinen individuellen Credentials auf dem SQL Server authentisiert.

Bestimmt stellt der Non-Trusted Fall eher die Ausnahme dar, wir waren im Zusammenhang mit unseren Kundenprojekten jedoch in dieser Situation und mussten deshalb rasch eine Lösung implementieren. Der Aufwand, für jeden Benutzer ein eigenes DBC zu erstellen erschien und allzu gross. Wir hatten das schon programmiert, haben aber diese Lösung wieder verworfen, da wir uns gesagt haben, wenn man sich stur an die "share connection" hält, braucht es keine solch "aufwendigen" Lösungen. Einfache Lösungen sind oftmals auch die besten.

Arbeiten ohne DSN Einträge

Wir hatten in der Vergangenheit akzeptiert, dass der Kunde beim Betreiben unserer Client/Server Anwendungen mit einem Data Source Name arbeitet. Hierzu musste immer eine ODBC Verbindung mit dem ODBC Data Source Administrator erstellt werden. Diese Information wurde in der Registry abgespeichert. An und für sich keine schwierige Angelegenheit aber eigentlich eine

1. überflüssige,
2. fehleranfällige
3. und v.a. nicht transparente

Lösung. Überflüssig deshalb, weil es auch ohne DSN Eintrag geht, fehleranfällig, weil in diesem Dialog viel zu viele Parameter falsch eingestellt bzw. verstellt werden können und nicht transparent, weil man vom Namen der DSN verbindung nicht direkt auf die effektiv angesprochene Datenbank schliessen konnte.

Dies hat uns dazu bewogen, nach einer Lösung zu suchen, welche und von diesem DSN "Gips" befreit. Die Lösung ist folgende:

PROCEDURE onpostlogin 
dodefault() 

*--dsn ggfl. setzen 
local lndsnhandle, llcancel 
do while .T. 
* DSN-less Connection 
local lcConnectionString 
lcConnectionString = "DRIVER=" + alltrim(m.gs_DRIVER) +; 
";SERVER=" + alltrim(m.gs_SERVER) +; 
";DATABASE="+ alltrim(m.gs_DATABASE) 

if !empty(m.gs_sqluser) 
lcConnectionString = lcConnectionString + ";UID=" + 
alltrim(m.gs_sqluser) +; ";PWD=" + 
alltrim(m.gs_sqlpass) 
else 
lcConnectionString = lcConnectionString + iif(m.gs_Trusted, ";TRUSTED_CONNECTION=Yes","") 
endif 

dbsetprop("conGV", "CONNECTION", "ConnectString", 
lcConnectionString) 

* Prüfe ob Verbindung zum Datenbankserver aufgebaut werden kann 
wait window "Prüfe Verbindung zum Server..." nowait 

lndsnhandle = sqlconnect("conGV") 
if lndsnhandle < 0 
do form form\DSNDialog TO llCancel 
if ! llCancel 
loop 
endif 
else 
if nvl(lndsnhandle,0) > 0 
sqldisconnect(lndsnhandle) 
lnsqlhandle = .NULL. 
endif 
endif 

if llCancel 
messagebox("Die Verbindung zum Server konnte nicht 
hergestellt werden." +ID_CRLF+; 
"Die Applikation wird nun beendet.", 16, 
_screen.caption) 
* Applikation beenden 
return .F. 
endif 
exit 
enddo 

*--öffne eine remote view mit shared connection zu Beginn 
use gv!rvstart nodata 
LOCAL lnConnection, lcSQL, llok, lnok 
llok = .T. 
lnConnection = Cursorgetprop("ConnectHandle") 
if lnConnection < 0 
llok = .f. 
else * app spezifisches 
endif 

endproc

Wir haben beim Start der Applikation den Connection String aufgebaut und setzten diesen mit dbsetprop im DBC ein. Ein typischer Connection String ohne DSN sieht folgendermassen aus:

DRIVER=SQL Server;SERVER=MYTHEN;DATABASE=GVaoUBS;TRUSTED_CONNECTION=Yes

Die benötigten Informationen, um auf den SQL Server zuzugreifen sind in einer Systemparameter Tabelle (vfxsys) abgespeichert. Diese sind im einzelnen:

• Der ODBC Treiber, hier muss für den SQL Server der String "SQL Server" stehen,
• der Servername sowie
• die Datenbank.

Wahlweise kann mit Trusted Connections oder, wie in dieser Anwendung, mit einem Proxy User unter SQL Server Security gearbeitet werden. Hat man keinen externen DSN Eintrag, so kann man die Applikation natürlich auch nicht starten, wenn die Einstellungen noch nicht in der Systemtabelle stehen. Um dieses Problem zu lösen, muss ein spezieller Dialog zur Verfügung gestellt werden, welcher dafür sorgt, dass der Benutzer (oder Administrator der die Anwendung aufsetzt) die erforderlichen Parameter beim erstmaligen Applikationsstart einstellen kann. Dies erfolgt im Form "dsndialog", welches sich dem Benutzer folgendermassen präsentiert:

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]