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

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 mir 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.

Datentypen auf dem SQL Server

SQL Server Feldtyp  VFP Äquivalent  Bemerkungen 
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[(p[, s])] , wobei p die Precision und s die Scale darstellt. Je nach verwendeter Precision wird eine andere Anzahl Bytes benötigt: Precision 1-9 benötigen 5 byte, 10-19 benötigen 9 bytes, 20-28 benötigen 13 und 29-38 benötigen 17 bytes. Lassen Sie sich dadurch nicht verwirren. Unser Feld "ParentValue" in der Parent Tabelle wird mit numeric und der Länge 5 beim SQL Server abgespeichert. Unsere Definition von numeric 6,2 ist auf dem SQL Server folgendermassen interpretiert worden: precision 6, scale 2 mit einem Speicherbedarf von 5 Byte. Das bedeutet, dass zwei Nachkommastellen verwendet werden und mit den beiden Nachkommastellen insgesamt 6 Stellen zur Verfügung stehen, d.h., dass im Gegensatz zu VFP der Dezimalpunkt nicht mitberücksichtigt wird.
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.

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:

 

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.

Identity Felder

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 verschohnt bleiben:

  • Es kann nur ein Identity Feld pro Tabelle geben
  • Ein Identity Feld kann nicht verändert werden
  • Ein Identity Feld kann nicht .NULL. Werte enthalten
  • Ein Identity Feld muss vom Typ int (auch smallint, tinyint) oder numeric sein
  • SELECT @@IDENTITY liefert den pro Connection zuletzt vergebenen Key zurück.

So weit so gut mag man sagen, doch da gibt es auch Problemsituationen:

Wird nach dem Insert einer Tabelle mit 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.

Uniqueidentifier Felder

Der Feldtyp uniqueidentifier und die Funktion NEWID() 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:

  • Speichert key als 16-byte (128-bit)
  • die NEWID() Funktion kann als GUID (Global Unique Identifier) Generator verwendet werden. Meistens direkt als Default Constraint. (s.n auch Bsp. oben)

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.

Erstmaliges Erstellen der Datenbank

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.

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