In dieser Session werden zu Beginn die grundlegenden Unterschiede zwischen einer Fileserver und einer Client/Server basierten Anwendungsarchitektur beschrieben. Es wird mit xCase ein Datenmodell erstellt, welches auf SQL Server 7.0 appliziert wird. Hierbei werden im Speziellen auch die Datums und Numerischen Datentypen angesprochen. Es werden alle notwendigen SQL Server 7.0 Grundlagen rund um den Enterprise Manager, den Profiler, den Query Analyzer, sowie über Constraints und Triggers vermittelt, um mit VFP effiziente Client/Server Anwendungen entwickeln zu können. In Analogie zur Rushmore Optimierung bei VFP Anwendungen wird gezeigt, wie beim SQL Server das Prüfen auf optimierte Queries mit dem SQL Server Execution Plan erfolgt. Schliesslich wird anhand des VFP/Client/Server Frameworks Visual Extend aufgezeigt, wie eine Client/Server Lösung grundsätzlich aufgebaut sein kann und wie die Notwendigkeiten einer Client/Server Lösung mit den aus der Fileserver Entwicklung her bekannten Leistungsmerkmalen zu einer attraktiven Gesamtlösung verbunden werden können. Diese Session ergänzt die anderen beiden Client/Server Sessions.
Jeder, der bereits erste Schritte in der Client/Server Welt unternommen hat oder ganz neu in diese Umgebung eintaucht, findet in dieser Session einen hervorragenden Einstieg und Überblick. Der Teilnehmer kann nach dieser Session sofort mit dem Entwickeln von Client/Server Anwendungen beginnen oder für seine laufenden Projekte entsprechende Informationen beziehen und direkt umsetzen. Es wird lediglich vorausgesetzt, dass ein gewisses Grundverständnis bzgl. der Aufteilung in einen Daten und einen Client Tier eine 2-Tier Client/Server Datanbankanwendung ausmacht.
Wir alle waren in der Zeit der File basierten Datenbanken à la FoxPro sehr verwöhnt. Wir haben uns mit der Frage, welche Daten dem Anwender in einer Applikation präsentiert werden, nicht unbeding auseinandersetzen müssen. Zumindest konnten wir uns vor dieser Frage etwas drücken und die Vorteile eines Index Sequentiellen Dateisystems, wie FoxPro eines ist, zu unserem Vorteil nutzen. In einer File Server basierten Lösung stehen uns durch das öffnen einer Tabelle die darin enthaltenen Datensätze uneingeschränkt zur Verfügung. Ein "Locate" oder "Seek" genügt, um auf einen bestimmten Datensatz zu positionieren. Man spricht in diesem Zusammenhang deshalb oft auch von einer "Seek" basierten Umgebung.
Alle File basierten Datenbankanwendungen haben u.A. jedoch leider immer wieder mit demselben Grundproblem zu kämpfen: Bei steigender Benutzerzahl und grösser werdenden Indexdateien wird die resultierende Netzwerkbelastung immer höher. Stellt man sich vor, dass viele Benutzer gleichzeitig eine Datei mit einer 20MB grossen Index Datei wiederholt öffnen und darauf zugreifen, wird einem bewusst, welche Netzwerkbelastung dadurch entsteht. VFP muss nämlich für jeden Benutzer, der eine Tabelle öffnet, den ganzen aktiven Index Tag über das Netzwerk herunterladen. Deshalb sind auch die CDX Dateien in VFP komprimiert. Tatsache ist, dass VFP, genauso wie alle Fileserver Datenbanken, über keinerlei Server Intelligenz verfügt, alles, wirklich alles, erfolgt im Arbeitsspeicher der Arbeitsstation! Egal ob Rushmore zur Anwendung gelangt oder nicht, sobald direkt auf “dbf” Dateien zugegriffen wird, hat man erneut eine entsprechende Netzbelastung, da grundsätzlich alles in den Arbeitsspeicher des Benutzer runtergeladen werden muss bevor damit etwas angefangen werden kann.
Der grundsätzlichste Unterschied zwischen einer Client/Server Umgebung und einer "Seek" basierten Umgebung besteht darin, dass in einer Client/Server Umgebung die Daten durch den Client immer zuerst beim Server angefordert werden müssen. Somit stellt sich die Frage "welche Daten zu beziehen sind" unweigerlich und in allererster Instanz. Da die verwendete normierte Abfragesprache in diesem Zusammenhang SQL (Structured Query Language) ist, spricht man auch von einer "SQL" basierten Umgebung.
Wenn wir die Datenumgebung eines Forms aus einer Fileserver Umgebung mit derjenigen aus einer Client/Server Umgebung vergleichen, fällt uns zunächst nichts besonderes auf. Auf den zweiten Blick sind es aber gerade die Relationen zwischen den einzelnen Tabellen, welche bei der Fileserver Umgebung unsere Aufmerksamkeit verdienen sollten. Das explizite Vorhandensein aller relational verbundenen Tabellen ist ein sehr wichtiger Sachverhalt. Sind es doch gerade die Tabellen, welche in der Datenumgebung einer Fileserverumgebung auftauchen, welche zu der eingangs erwähnten Performance Problematik beim Öffnen des Forms führen.
Beispiel einer Datenumgebung eines Forms bei einer Fileserver Umgebung:
Im Gegensatz dazu ist bei derselben Funktionalität bei einem Client/Server Form die Datenumgebung “leichter”:
Statt Relationen in der Datenumgebung finden wir die “Table Joins” in der View Definition:
Der aber wirklich alles entscheidende Unterschied liegt hierbei darin, dass diese “Joins” auf dem Server abgewickelt werden und überhaupt keinen Einfluss auf die Netzbelastung oder die Rechenleistung des Arbeitsplatzes haben.
Wenn man diesen fundamentalen Unterschied einmal “verinnerlicht” hat, versteht man, dass die Vorteile einer Trennung zwischen dem Client und dem Daten Tier absolut Sinn macht! Man freut sich dann jedesmal entsprechend, wenn man dem Daten Tier wieder mal einen Haufen Arbeit (in Form von komplexen SQL Abfragen über mehrere Tabellen) zuschaufeln kann.
Der SQL Server Enterprise Manager bietet grundsätzlich alle Möglichkeiten, eine Datenbank aufzusetzen, Tabellen zu definieren, Indices aufzusetzen sowie Constraints, Rules und Triggers zu implementieren. In der SQL Server Books Online Dokumentation finden sich hierzu genügend Informationen, so dass ein Verweis auf diese Referenz an dieser Stelle genügt.
Für diejenigen, welche xCase bereits für die Datenmodellierung ihrer VFP Datanbanken verwendet haben, ist es ein Leichtes, dasselbe Tool, mitlerweile in der Version 5.0, auch für SQL Server 7.0 einzusetzen.
Obwohl es auch aus xCase heraus möglich ist, die Datenbank physisch auf SQL Server anzulegen, ziehe ich es vor, diesen Schritt im SQL Server Enterprise Manager zu bewerkstelligen. Da bei MSDE Implementationen kein Enterprise Manager zur Verfügung steht, muss man für die Distribution der MSDE basierten Anwendung ein wenig anders vorgehen, ich werde dies am Ende der Session noch kurz anschneiden. Soviel sei aber schon einmal verraten: auch eine MSDE Datenbank Installation kann von einem beliebigen Enterprise Manager im Netz administriert werden, hierzu genügt es, den entsprechenden Server zu registrieren!
Um eine neue Datenbank anzulegen, genügt es, auf “Databases” zu gehen und dort im “RightMouseClick” Kontextmenu die Option “New Database…” anzuwählen.
Im erscheinenden Dialog “Database Properties” geben Sie den Namen der neu zu erstelenden Datenbank ein. Es wird vorgeschlagen ein Master Data File (Endung MDF) im Data Unterverzeichnis Ihrer SQL Server Installation mit dem Namen der zu erstellenden Datenbank anzulegen. Hier müssen Sie intervenieren, wenn Sie die Datenbank auf einem anderen Laufwerk oder in einem anderen Verzeichnis wünschen. Geben Sie die Initialgrösse nicht zu gross ein. Diejenigen, die SQL Server 6.5 kennen, werden es sehr schätzen, dass man jetzt nicht zuerst sogenannte Devices fixer Grösse anlegen muss. Stattdessen ist SQL Server 7.0 nun in der Lage die Datenbank bei Bedarf entsprechend zu vergrössern. Die entsprechende Option “Automatically grow file” ist standardmässig bereits aktiviert.
Auf der Seite “Transaction Log” können Sie noch die Grösse des Logfiles angeben. Je nachdem, ob Ihre Anwendung viel schreibt, oder mehr liest, ist das Logfile entsprechend grösser oder kleiner zu machen.
Um via ODBC auf die soeben erstellte Datenbank zugreifen zu können tun wir gut daran, sofort eine entsprechende ODBC Verbindung zu definieren. Dies geschieht mit dem “ODBC Data Source Administrator” aus dem Windows Control Panel. Weil dieser Punkt mit einer “netten” Benutzeroberfläche bewerkstelligt wird, werden in der Praxis hier leider immer wieder Fehler begangen. Es ist bedauernswerterweise viel zu einfach, hier Einstellungen abzusetzen, welche Ihre gesamte Anwendung ziemlich alt aussehen lassen können. Deshalb ist es sehr wichtig, dass Sie auch dieser scheinbaren “Nebensächlichkeit” Ihre volle Aufmerksamkeit widmen. Folgende Punkte sind unbedingt zu beachten:
Es muss sichergestellt werden, dass die gewünschte Datenbank angewählt wird. Wenn nach Anwählen der gewünschten Datenbank und betätigen der “Back” und wieder “Next” Taste die Auswahl wieder entfernt erscheint, bedeutet dies, dass Sie mit dem verwendeten User keine Berechtigung auf der angewählten Datenbank besitzen. Stellen Sie sicher, dass Sie genügend Berechtigung haben, oder verwenden Sie einen Login, wie z.B. den “sa” Login mit entsprechendem Passwort, falls Sie als Entwickler an dieser Stelle unbeding weiter kommen müssen.
Wenn die Datenbank auf dem SQL Server angelegt ist, kann aus xCase heraus das Modell abgesetzt werden. Hierzu erstellen wir zunächst ein neues Modell in xCase:
Um in xCase ein neuese Modell zu erstellen, wählen Sie “File/New” und im erscheinenden “New model” Dialog geben Sie am besten denselben Namen ein, den Sie im Enterprise Manager eben vergeben haben.
ACHTUNG: “SQL SERVER” und “SQL SERVER 7” sind zwei verschiedene DBMS, bitte beachten Sie hier, dass sie “SQL Server 7 anwählen. Sollten Sie aus Versehen Ihr Modell bereits unter “SQL SERVER” erstellt haben, so wählen Sie den Menupunkt “DataBase/ Copy Model with Different Target DBMS…” um Ihr Modell in die gewünschte “SQL SERVER 7” Version zu bringen.
Nun erstellen wir drei Tabellen, eine “PARENT”, eine “CHILD” sowie eine “ITEM”. Ganz generell ist bei einer neuen Datenmodellierung Folgendes zu beachten:
Verwenden Sie nach Möglichkeit “surrogate” integer keys als Primary Keys. Optional: Verwenden des Identity Typs wobei dann mit der @@identity Funktion der jeweils zuletzt gelesene Schlüsselwert bezogen werden kann, falls benötigt (s. auch Bemerkungen weiter unten)
Denken Sie immer daran, dass alle Objekte in einer SQL Server Datenbank einen Eindeutigen Namen benötigen: “Server.Datenbank.Owner.Objekt”. Das heisst insbesondere, dass die im xCase erstellten Indices sowie die Constraints (via Relationen) eindeutige Namen aufweisen müssen, ansonsten können Sie Ihr Modell nicht auf dem SQL Server applizieren.
Ich habe mir angewöhnt, die Namen der Relationen nach dem Schema “TabelleVon_TabelleNach” zu benennen. In obigem Beispiel also “Parent_Child”. Das hat den Vorteil, dass im Falle von ODBC Fehlermeldungen in Folge “Constraint” Verletzungen, ein etwas anschaulicherer Name präsentiert wird. Das ist für die rasche Fehlererkennung manchmal sehr nützlich.
Dasselbe gilt auch für die Indices. Stellen Sie unbedingt sicher (xCase macht das leider nicht für Sie), dass Sie im gesamten Modell keine zweimal denselben Indexnamen verwenden.
Zu diesem Zweck sollten Sie sich auf jeden Fall alle Indexnamen noch einmal durchsehen. Als Konvention habe ich mit angewöhnt, den Primary Index auf “PK_TableName” zu belassen, die anderen Indices jedoch mit dem Tabellennamen zu prefixen. Auf diese Weise ist auf jeden Fall sichergestellt, dass es keine zwei gleichlautenden Indices in der gesamten Datenbank gibt.
Ein Thema für sich ist die Datentypen Problematik. Hier gibt es eine Menge an Konfusion, sicherlich auch nicht zuletzt deshalb, da bei den VFP Remote Views dbzgl. sehr oft einiges schief läuft. Um ein wenig Licht in das Dunkle zu bringen, hier einige Erläuterungen zu den wichtigsten Datentypen:
| SQL Server Feldtyp | VFP Äquivalent | Bemerungen |
|---|---|---|
|
SmallDateTime |
Date/ DateTime |
Zu Beachten ist hier, dass SmallDate auf dem SQL Server vom 1.Januar 1900 bis zum 6.Juni 2079 reicht und auf eine Minute genau ist. VFP verwendet bei SmallDateTime bei Remote Views standardmässig DateTime mit Stunden, Minuten sowie Sekunden und Millisekunden (immer 0). |
|
DateTime |
Date/DateTime |
DateTime reicht vom 1. Januar 1753 bis zum 31. Dezember 9999 und ist auf 3.33 Millisekunden genau. VFP verwendet auch bei DateTime bei Remote Views standardmässig DateTime mit Stunden, Minuten sowie Sekunden und Millisekunden. |
|
numeric |
num |
Hier ist zu erwähnen, dass SQL Server diese Felddefinition
grundsätzlich nach einem anderen Schema vornimmt als wir uns dies aus
VFP her gewöhnt sind, nämlich folgendermassen: |
|
decimal |
|
Synonym zu numeric! |
|
dec |
|
Synonym zu numeric! |
|
identity |
- |
Generierter, fortlaufender nummerischer Schlüssel. Eindeutig pro Tabelle. Siehe Erläuterungen unten. |
|
uniqueidentifier |
- |
Mit der Funktion NEWID() generierter, 128-bit Binärschlüssel, weltweit eindeutig. Siehe Erläuterungen unten. |
Um sich mit der Datentypen Problematik vertraut zu machen, lohnt es sich, den folgenden Dialog aus dem Enterprise Manager im “RightmouseClick” Kontextmenu unter “Design Table” etwas genauer anzuschauen:
Hier erkennen wir, dass für unser numeric 6,2 die Definition mit einer Precision (Anzahl Stellen inkl. Nachkommastellen, ohne Dezimalpunkt) von 6, und einer Scale (Anzahl Nachkommastellen) von 2 ein numerisches Feld von 5 Byte Länge erstellt wurde.
TIP: Es gibt eine einfache Eselsbrücke. Will man in der VFP Notation ein numerisches Feld der VFP Dimension 6,2 erstellen, lohnt es sich, dieses auch auf dem SQL Server mit 6,2 zu erstellen. Warum? Es ist dann zwar eine Vorkommastelle zu gross, das kommt aber dem bekannten ODBC Rundungsproblem im Zusammenhang mit ODBC Remote View Updates sehr entgegen! Sind die Felder auf dem SQL Server nämlich überdimensioniert, und werden in der Remote View Definition bewuss kleinere Feldlängen verwendet (wichtig!), dann kommen diese lästigen Rundungsprobleme viel weniger vor.
An dieser Stelle darf natürlich der Datentyp Identity nicht fehlen. Dieser ist in bestimmten Fällen sehr praktisch, kann aber bei sorgloser Verwendung durchaus auch zu Problemen führen. Mit der folgenden Syntax können Identity Felder angelegt werden:
CREATE TABLE table
(column_name numeric_data_type
IDENTITY [(seed, increment)]
Es sei folgendes erwähnt, damit Sie von bekannten Erfahrungen verschont bleiben:
So weit so gut mag man sagen, doch da gibt es auch Problemsituationen:
Wird nach dem Insert einer Tabelle mt Identity Colum ein weiterer Insert auf eine Tabelle abgesetzt, welche keine Identity Column besitzt, dann wird SELECT @@IDENTITY .NULL. zurückgeben. Auch wenn ein Audit Trigger einen weiteren Insert absetzt, wird die @@IDENTITY Abfrage natürlich nicht mehr das liefern, was man erwartet. Will man hier eine wirklich funktionierende Lösung implementieren, gibt es nur noch den Ansatz, dass man alle Inserts über Stored Procedures abwickelt, welche auch dafür verantwortlich sind, die zuletzt vergebenen Identity Keys unmittelbar zurückzugeben. Alles Andere birgt schlicht zu viele Risiken.
können gemeinsam verwendet werden, um 128-bit ID's zu generieren:
CREATE TABLE customer
(cust_id uniqueidentifier NOT NULL DEFAULT NEWID(),
cust_name char(30) NOT NULL)
Folgendes gilt bzgl. uniqueidentifier Feldern:
Dieser Feldtyp wird dann verwendet, wenn man sicherstellen muss, dass auf der gazen Welt niemals 2 identische ID's für eine verteilte Tabelle generiert werden. Vor allem bei Daten Replikationsstrategien verwendet.
Um das xCase Modell das erste Mal auf unsere Test Datenbank zu applizieren, wählen Sie den Menupunkt “DataBase/Create/Drop Database Objects…” an. In folgendem Dialog können Sie alles bei den Voreinstellungen belassen. Lassen Sie sich nicht dadurch irritieren, dass bei “Storage” nichts angewählt ist. Das bedeutet lediglich, dass die Datenbank physisch nicht nochmals anzulegen ist. Das haben wir ja vorhin auch schon explizit im Enterprise Manager getan.
Auch dass der Object Type “Indexes” nicht angewählt ist, d.h. auch auf “Nothing” steht, soll uns nicht weiter beunruhigen. Im Script, das xCase zum SQL Server sendet, sind die Indices nämlich bereits enthalten. Drücken Sie auf “Generate Script” und das Script unsere Datenbank zu erstellen wird von xCase generiert.
CREATE TABLE Parent
(
ParentID INT NOT NULL,
ParentDescr CHAR(40) NULL,
ParentValue NUMERIC(6,2) NULL,
CONSTRAINT PK_Parent PRIMARY KEY NONCLUSTERED
(ParentID)
)
go
CREATE TABLE Child
(
ChildID INT NOT NULL,
ParentID INT NOT NULL,
ChildDesc CHAR(40) NULL,
ChildType CHAR(1) NULL,
ItemID INT NOT NULL,
Quantity NUMERIC(6,0) NULL,
CONSTRAINT PK_Child PRIMARY KEY NONCLUSTERED
(ChildID)
)
go
CREATE NONCLUSTERED INDEX Child_Parent ON Child (ParentID)
go
CREATE NONCLUSTERED INDEX Child_Item ON Child (ItemID)
go
CREATE TABLE Item
(
ItemID INT NOT NULL,
ItemDescr CHAR(40) NULL,
ItemPrice NUMERIC(6,2) NULL,
ItemAvailability CHAR(1) NULL,
CONSTRAINT PK_Item PRIMARY KEY NONCLUSTERED
(ItemID)
)
go
ALTER TABLE Child
ADD CONSTRAINT Parent_Child FOREIGN KEY
( ParentID )
REFERENCES Parent
( ParentID )
go
ALTER TABLE Child
ADD CONSTRAINT Item_Child FOREIGN KEY
( ItemID )
REFERENCES Item
( ItemID )
go
/* Update Trigger 'T_U_Parent' for Table 'Parent' */
CREATE TRIGGER T_U_Parent ON Parent FOR UPDATE AS
BEGIN
DECLARE
@row_count INT,
@null_row_count INT,
@error_number INT,
@error_message VARCHAR(255)
SELECT @row_count = @@rowcount
IF @row_count = 0
RETURN
/* The Primary Key of 'Parent' cannot be modified if children exist in 'Child' */
IF UPDATE(ParentID)
BEGIN
IF EXISTS (
SELECT 1
FROM Child c, inserted i, deleted d
WHERE c.ParentID = d.ParentID
AND (i.ParentID != d.ParentID)
)
BEGIN
SELECT @error_number=30004,
@error_message='Children exist in "Child".
Cannot modify Primary Key in "Parent".'
GOTO error
END
END
RETURN
/* Error Handling */
error:
RAISERROR @error_number @error_message
ROLLBACK TRANSACTION
END
go
/* Delete Trigger 'T_D_Parent' for Table 'Parent' */
CREATE TRIGGER T_D_Parent ON Parent FOR DELETE AS
BEGIN
DECLARE
@row_count INT,
@error_number INT,
@error_message VARCHAR(255)
SELECT @row_count = @@rowcount
IF @row_count = 0
RETURN
/* Parent in 'Parent' cannot be deleted if children exist in 'Child' */
IF EXISTS (
SELECT 1
FROM Child c, deleted d
WHERE c.ParentID = d.ParentID
)
BEGIN
SELECT @error_number=30005,
@error_message='Children exist in "Child". Cannot delete parent "Parent".'
GOTO error
END
RETURN
/* Error Handling */
error:
RAISERROR @error_number @error_message
ROLLBACK TRANSACTION
END
go
/* Insert Trigger 'T_I_Child' for Table 'Child' */
CREATE TRIGGER T_I_Child ON Child FOR INSERT AS
BEGIN
DECLARE
@row_count INT,
@null_row_count INT,
@error_number INT,
@error_message VARCHAR(255)
SELECT @row_count = @@rowcount
IF @row_count = 0
RETURN
/* When inserting a row in child 'Child' ,the Foreign Key must be Null or exist in Parent 'Parent' */
IF UPDATE(ParentID)
BEGIN
SELECT @null_row_count =
(
SELECT COUNT(*)
FROM inserted
WHERE ParentID is null
)
IF @null_row_count != @row_count
IF (
SELECT COUNT(*)
FROM Parent p, inserted i
WHERE p.ParentID = i.ParentID
)
!= @row_count - @null_row_count
BEGIN
SELECT @error_number=30001,
@error_message='Cannot insert child in "Child" as its
Foreign Key does not exist in "Parent".'
GOTO error
END
END
/* When inserting a row in child 'Child' ,the Foreign Key must be Null or exist in Parent 'Item' */
IF UPDATE(ItemID)
BEGIN
SELECT @null_row_count =
(
SELECT COUNT(*)
FROM inserted
WHERE ItemID is null
)
IF @null_row_count != @row_count
IF (
SELECT COUNT(*)
FROM Item p, inserted i
WHERE p.ItemID = i.ItemID
)
!= @row_count - @null_row_count
BEGIN
SELECT @error_number=30001,
@error_message='Cannot insert child in "Child" as its
Foreign Key does not exist in "Item".'
GOTO error
END
END
RETURN
/* Error Handling */
error:
RAISERROR @error_number @error_message
ROLLBACK TRANSACTION
END
go
/* Update Trigger 'T_U_Item' for Table 'Item' */
CREATE TRIGGER T_U_Item ON Item FOR UPDATE AS
BEGIN
DECLARE
@row_count INT,
@null_row_count INT,
@error_number INT,
@error_message VARCHAR(255)
SELECT @row_count = @@rowcount
IF @row_count = 0
RETURN
/* The Primary Key of 'Item' cannot be modified if children exist in 'Child' */
IF UPDATE(ItemID)
BEGIN
IF EXISTS (
SELECT 1
FROM Child c, inserted i, deleted d
WHERE c.ItemID = d.ItemID
AND (i.ItemID != d.ItemID)
)
BEGIN
SELECT @error_number=30004,
@error_message='Children exist in "Child".
Cannot modify Primary Key in "Item".'
GOTO error
END
END
RETURN
/* Error Handling */
error:
RAISERROR @error_number @error_message
ROLLBACK TRANSACTION
END
go
/* Delete Trigger 'T_D_Item' for Table 'Item' */
CREATE TRIGGER T_D_Item ON Item FOR DELETE AS
BEGIN
DECLARE
@row_count INT,
@error_number INT,
@error_message VARCHAR(255)
SELECT @row_count = @@rowcount
IF @row_count = 0
RETURN
/* Parent in 'Item' cannot be deleted if children exist in 'Child' */
IF EXISTS (
SELECT 1
FROM Child c, deleted d
WHERE c.ItemID = d.ItemID
)
BEGIN
SELECT @error_number=30005,
@error_message='Children exist in "Child". Cannot delete parent "Item".'
GOTO error
END
RETURN
/* Error Handling */
error:
RAISERROR @error_number @error_message
ROLLBACK TRANSACTION
END
go
Wie Sie sehen, ist dieses Script tatsächlich vollständig, neben den Tabellen, Indices und Constraints hat xCase sogar die Update und Delete Triggers erstellt, um sicherzustellen, dass nicht Primärschlüssel in der “Parent” oder “Item” Tabelle verändert werden können, wenn gleichzeitig abhängige Daten dazu vorhanden sind.
xCase unterstützt einen grundsätzlich auch darin, seine Strukturänderungen auf der Datenbank zu applizieren. Hierzu verwendet xCase den Ansatz, eine neue Tabelle mit der angepassten Struktur zu erstellen, in diese Tabelle die Daten aus der alten Tabelle einzufügen, die alte Tabelle zu löschen und schliesslich die neu erstellte Tabelle in den ursprünglichen Namen umzubenennen. Hier ein Beispiel:
CREATE TABLE TEMP_Item
(
ItemID INT NOT NULL,
ItemDescr CHAR(40) NULL,
ItemPrice NUMERIC(6,2) NULL,
ItemAvailability CHAR(1) NULL,
test CHAR(10) NULL
)
go
INSERT INTO TEMP_Item (ItemID,ItemDescr,ItemPrice,ItemAvailability)
SELECT ITEMID,ITEMDESCR,ITEMPRICE,ITEMAVAILABILITY
FROM Item
go
IF EXISTS (SELECT 1 FROM sysobjects WHERE name = 'Item' AND type = 'U')
DROP TABLE Item
go
EXECUTE sp_rename 'TEMP_Item', 'Item', 'OBJECT'
go
Um diese Schritte jedoch durchführen zu können, müssen zunächst alle Referenzen zur alten Tabelle entfernt werden und anschliessend wieder erstellt werden. Obwohl xCase das prinzipiell auch versucht zu tun, gelingt es je nach Komplexität und Abfoge der Abhängigkeiten nicht immer auf Anhieb. Das liegt u.a. auch daran, dass xCase die Tabellen nicht in einer logischen Abhängigkeit abarbeitet, sondern stur alphabetisch, was natürlich füher oder später zu Problemen führt.
Wird im SQL Server nicht mit dem 6.5 Kompatibilitätsmodus gearbeitet, ist es manchmal viel einfacher bei simplen Strukturänderungen direkt die T-SQL Scripts abzusetzen:
alter table adresse add einzug char(1)
um eine Spalte hinzuzufügen, bzw.
alter table bank drop column einzug
um eine Spalte zu entfernen. Bei Feldtypenänderungen, wie eine einfache Stellenerweiterung, kann auch mit dem Alter Table Script operiert werden.
WICHTIG: Denken Sie daran, dass xCase die Triggers nicht von sich aus aktualisiert. Sie müssen die Triggers explizit neu generieren lassen, damit diese nach umfangreichen Datenstrukturänderungen wieder funktionstüchtig sind.
Wir haben in obigem Script gesehen, wie eine Foreign Key Constraint aussieht und wir haben auch gesehen, wie ein Update oder Delete Trigger augebaut ist. Es lohnt sich hier näher darauf einzugehen, damit man in der Praxis genau weiss, wann welches Konstrukt zu verwenden ist.
Constraints sind wenn immer möglich Triggern oder Rules vorzuziehen. Rules sollten nach Möglichkeit gar nicht mehr verwendet werden. Sie sind nur wegen Rückwärtskompatibilität vorhanden.
Constraints sind proaktiv, Triggers hingegen reaktiv. Das heisst, dass Constraints versuchen, etwas sicherzustellen, bevor es in der Datenbank zu einem unerwünschten Zustand kommt, die Triggers hingegen kommen erst dann zum Zug, wenn ein womöglich unerwünschter Zustand bereits eingetreten ist, der dann wieder zurückgestellt werden muss. Das ist natürlich viel aufwendiger, als bei den Constraints, deshalb sollte wenn immer möglich mit Constraints gearbeitet werden.
Es gibt folgende Arten von Constraints:
| Constraint | Syntax Beispiel | Beschreibung |
|---|---|---|
|
PRIMARY KEY |
CREATE TABLE Child ( ChildID INT NOT NULL, ParentID INT NOT NULL, ChildDesc CHAR(40) NULL, ChildType CHAR(1) NULL, ItemID INT NOT NULL, Quantity NUMERIC(6,0) NULL, CONSTRAINT PK_Child PRIMARY KEY NONCLUSTERED (ChildID) ) |
Stell auf Stufe Tabelle sicher, dass in einer Tabelle nicht zweimal derselbe Primärschlüssel vergeben werden kann |
|
FOREIGN KEY |
ALTER TABLE Child ADD CONSTRAINT Parent_Child FOREIGN KEY ( ParentID ) REFERENCES Parent ( ParentID )
|
Stellt referentiell sicher, dass nicht ein nicht existierender Fremdschüssel (inkl. Leer Einträge, nicht .null.) in das entsprechende Feld eingetragen werden kann |
|
UNIQUE |
ALTER TABLE Parent ADD CONSTRAINT my_unique UNIQUE ( ParentDescr )
|
Stellt sicher, dass es nicht mehrere gleiche Einträge bzgl. Dem entsprechenden Feld oder Ausdruck gibt |
|
DEFAULT |
ALTER TABLE Child ADD CONSTRAINT my_default DEFAULT 'Unknown' FOR CHILDDESC |
Stellt auf Tabellenebene sicher, dass alle neu angelegten Datensätze einen bestimmten Standardwert für bestimmte Felder erhalten, sofern nicht explizit ein Wert angegeben wird |
|
CHECK |
ALTER TABLE Child ADD CONSTRAINT my_check CHECK (CHILDTYPE='A' or CHILDTYPE='B')
|
Stellt sicher, dass nur bestimmte Werte für ein bestimmtes Feld in Frage kommen. |
TIP: Um eine Constraint wieder zu entfernen, können Sie im Query Analyzer folgendes eingeben:
alter table child drop constraint my_check
Es gibt folgende Arten von Triggers
| Trigger | Syntax Beispiel | Beschreibung |
|---|---|---|
|
UPDATE |
CREATE TRIGGER T_U_Parent ON Parent FOR UPDATE AS
BEGIN DECLARE @row_count INT, @null_row_count INT, @error_number INT, @error_message VARCHAR(255)
SELECT @row_count = @@rowcount IF @row_count = 0 RETURN
/* The Primary Key of 'Parent' cannot be modified if children exist in 'Child' */
IF UPDATE(ParentID) BEGIN IF EXISTS ( SELECT 1 FROM Child c, inserted i, deleted d WHERE c.ParentID = d.ParentID AND (i.ParentID != d.ParentID) ) BEGIN SELECT @error_number=30004, @error_message='Children exist in "Child". Cannot modify Primary Key in "Parent".' GOTO error END END RETURN
/* Error Handling */ error: RAISERROR @error_number @error_message ROLLBACK TRANSACTION END |
Wird dann ausgeführt, nachdem ein Update stattgefunden hat. HINWEIS: Sehr häufig verwendet man die Anweisung UPDATE(FeldName) um im Trigger Code festzustellen, ob ein Feldinhalt verändert wurde. Detaillierter UPDATE Ablauf: 1. UPDATE Statement wird ausgeführt und ein UPDATE Trigger existiert 2. Das UPDATE Statement wird geloggt als einzelne INSERT und DELETE statements. 3. Der Trigger schiesst los und die Trigger Statements werden abgearbeitet. Hierbei kann der alte Datensatz in der virtuellen Tabelle Namens “deleted”, der neu hinugefügte unter dem Namen “inserted” angesprochen werden. |
|
INSERT |
CREATE TRIGGER T_I_Parent ON Parent FOR INSERT AS
BEGIN …
|
Wird dann ausgeführt, nachdem ein Insert stattgefunden hat. Detaillierter INSERT Ablauf: 1. INSERT Statement wird ausgeführt bei einer Tabelle mit einem INSERT Trigger 2. Das INSERT Statement wird geloggt 3. Der INSERT Trigger schiesst los und die Trigger Statements werden abgearbeitet. Hierbei kann der neue Datensatz sowohl in der virtuellen Tabelle Namens “inserted”, als auch in der Tabelle selbst angesprochen werden. |
|
DELETE |
CREATE TRIGGER T_D_Parent ON Parent FOR DELETE AS
BEGIN |
Wird dann ausgeführt, nachdem ein Delete stattgefunden hat. Detaillierter DELETE Ablauf: 1. DELETE Statement wird ausgeführt bei einer Tabelle mit einem DELETE Trigger 2. Das DELETE Statement wird geloggt Der DELETE Trigger schiesst los und die Trigger Statements werden abgearbeitet. Hierbei kann der gelöschte Datensatz in der virtuellen Tabelle Namens “deleted” angesprochen werden. |
HINWEIS: Triggers sind natürlich auch ausgezeichnet dafür geeignet, Audit Trails zu erstellen. Ich werde in der Session zeigen, wie Audit Trails implementiert werden können und worauf dabei zu achten ist.
Der Query Analyzer ist der ständige Begleiter eines jeden Client/Server Entwicklers. Genauso wie der Enterprise Manager und der Profiler gehört er zum täglich verwendeten Hilfsmittel.
Bevor man mit dem Query Analyzer arbeiten kann, muss man sich mit einem SQL Server verbinden, das erfolgt über den “Connect” Dialog. Dieser kann jederzeit aus dem File Menu heraus aufgerufen werden:
Anschliessend erhält man folgenden Dialog, um seine Arbeiten zu erledigen:
Es ist wichtig, dass man die gewünschte Datenbank unter der Combobox “DB:” anwählt. In diesem Fall wurde die Datenbank “test1” angewählt.
Der Query Analyzer ist quasi das Standard Sprachrohr zum SQL Server. Im oberen Bildschirmbereich geben Sie die T-SQL Befehle ein, führen diese entweder durch Selektion und CTRL+E oder den grünen Pfeil in der Toolbar aus.
In der unteren Hälfte des Bildschirmes erhalten Sie einen Feedback. Falls der abgesetzte T-SQL Befehl Datensätze zurückgibt, werden diese in der unteren Hälfte angezeigt. Hierzu ist es manchmal nützlich zu wissen, dass es eine Option “Results in Grid” gibt, welche das Resultat statt in ein Textfile in ein Grid mit Zeilen und Spalten stellt.
Ebenso überlebensnotwendig ist der Execution Plan. Seit der Version 7.0 gibt es Ihn nun auch graphisch. Das ist, ähnlich wie bei den DTS Packages vielleicht ein wenig verspielt, aber praktisch ist es schon. Vor allem, wenn man eine wirklich komplizierte Query absetzt. Hier ein ganz einfaches Beispiel:
Dieser Execution Plan ist es, der Ihnen ehrlich und unbeschönigt sagt, ob Ihre geniale Select Anweisung nun optimiert werden kann oder nicht. Wenn Sie irgendwo “Table” Scans sehen, dann haben Sie schlechte Karten. Das bedeutet nämlich, dass alle Datensätze auf dem SQL Server einzeln durchgegangen werden. Es ist klar, dass bei einer grösser werdenden Tabelle die Antwortzeiten entsprechend grösser werden.
Der Profiler ist quasi der Spion, der alles aufzeichnet, was beim SQL Server wirklich ankommt. Das ist vor allem dann sehr nützlich, wenn eine Remote View “defekt” ist und wirre Fehlermeldungen resultieren.
Um eine neue Trace Spur aufzusetzen, muss man sich durch den Trace Properties Dialog durcharbeiten. Es gibz dort eine Reihe von Einstellungen, um die individuellen Trace Bedürfnisse abzudecken. Vor allem auch wenn auf einem SQL Server verschiedene Programme betrieben werden während dem man einen Trace startet ist es unumgänglich, den eigenen Trace sinnvoll einzuschränken.
Will man mit der SQL Server 7.0 Platform seriös arbeiten, kommt man natürlich auch nicht um die DTS herum. Diese sind so leistungsfähig und vielseitig einsetzbar, dass ich an dieser Stelle nur das wichtigste aufzeigen kann. Ich denke aber, dass es einfach ist, nach einer kurzen Einführung eigene DTS Pakete entweder Wizard gesteuert zu erstellen, oder aber mit VB Script und VFP COM Komponenten anzureichern. Dadurch lassen sich nun wirklich alle nur denkbaren Daten Imports und Exports zwischen SQL Server, VFP oder irgendwelchen anderen via ODBC oder ADO zugänglichen Datenbanken und Fileformaten bewerkstelligen.
Ich werde während der Session ein einfaches DTS Beispiel, sowie eines mit VB Script Erweiterungen und eines mit einer VFP 6.0 COM Komponentenerweiterung zeigen. Hat man das einmal gesehen, ist DTS tatsächlich kein Buch mehr mit sieben Siegeln, sondern eine wirklich nützlich Datentransformationsumgebung.
VFX ist ein Framework, welches vor allem seit der Version 6.0 sehr weitreichende Client/Server Funktionalitäten beinhaltet und in diese Richtung auch laufend weiter entwickelt wird.
Eine mit VFX 6.0 entwickelte Client/Server Anwendung lebt auch dem Grundgedanken nach, dass nicht beliebige Daten vom Server zum Client transferiert werden, sondern dass der Benutzer bevor er irgendwelche Daten zu Gesicht bekommt, diese explizit anfordern muss.
Nun gibt es sicher verschiedenste Möglichkeiten, den Benutzer aufzufordern, er solle sich für einen Datenbezug entscheiden. Im VFX Framework wird dies folgendermassen vollzogen.
Wenn der Benutzer ein Form startet, wird Ihm zunächst eine Selektionsmaske, welche auf der Klasse CAskViewArg bzw. bei unterschiedlichen Datenabfragevarianten auf demselben Form, af der Klasse CAskViewArgPgf basiert. Im folgenden Beispiel wird die Verwendung mit der Klasse CAskViewArgPgf erläutert.
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:
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.
Die Distribution von Client/Server Anwendungen mit MSDE ist dank vorgefertigter Installationsroutine eigentlich recht leicht zu bewerkstelligen. Will man jedoch in ein und derselben Installationsumgebung dem Benutzer die Möglichkeit geben
Wir haben zu diesem Zweck mit VB 6.0 ein Installations Paket geschrieben, welches all diese Punkte transparent abdeckt und Ohne VB Programmierkenntnisse den eigenen Bedürfnissen angepasst werden kann.
Ich werde dieses “Advanced MSDE Installation Environment”, welches, webenso wie das VFP Applikations Framework VFX, von der Firma Devigus Engineering AG mit Sitz in CH-6343 Rotkreuz erstellt und vertrieben wird, detailliert vortstellen. Sie werden sehen, damit macht selbst das Distribuieren von Client/Server Anwendungen kein Unbehagen mehr, sondern bereitet echt Freude.