Hallo, Jimmy -
da stehst Du wieder vor einer Entscheidung ...
macht einen Satz tot, mausetot. NO RECOVERY (es sei denn, Du wühlst im Hex-Dump der Datenbank rum).
Alaska bildet mit den internen Feldern DBF-Strukturen ab, um eben doch noch ein RECALL durchführen zu können.
Wenn Du die pgDBE verwenden willst, musst Du solche Dinge berücksichtigen, allerdings denke ich, dass Alaska je nach SET DELETED ON/OFF diese Sätze rausfiltert oder durchlässt.
Nächster Punkt ... für Tabellen, bei denen Du nicht die Hoheit über den Schlüssel haben willst (musst), kannst Du AUTOINCREMENT verwenden. Damit wird bei der Anlage eines neuen Satzes automatisch der Wert auf Max(nKeyFeld) + 1 gesetzt.
1
2
3
neuer Satz: 4
1
3
5
neuer Satz: 6
Je nach Implementierung im Server kann Dir folgendes passieren: nehmen wir das letzte Beispiel, nach der Anlage des vierten Satzes (Schlüsselfeld hat den Wert 6 automatisch erhalten), führst Du ein
DELETE FROM table aus, und legst einen neuen Satz an. Der bekommt dann als Schlüsselwert ... entweder 1, oder 7 - je nach dem, wie das AUTOINCREMENT implementiert ist.
Das ist einer der Gründe, warum ich AUTOINCREMENT vermeide, da ich in den meisten Fällen eben die Hoheit darüber haben will, welche Schlüsselwerte verwendet werden. Nehmen wir eine Mitarbeiterdatei mit unterschiedlichen Stammnummernkreisen (nein, ich verwende keine sprechenden Schlüssel, aber über diese Dinge entscheiden eben Personalabteilungsmitarbeiter), da wäre AUTOINCREMENT einfach tödlich.
PRIMARY KEY ist etwas völlig anderes als das UNIQUE unter Xbase, siehe die Diskussionen um "verschwundene" Sätze in Index-Dateien mit UNIQUE-Attribut. UNIQUE heisst bei einem SQL Server UNIQUE, d.h. einmalig. Die Anlage eines neuen Satzes mit gleichem Schlüssel wird geblockt, das Ändern eines Satzes (Schlüsselfeld), wodurch ein doppelter Schlüssel entstehen würde, wird ebenfalls geblockt.
Ein PRIMARY KEY kennt auch keine Bedingungen, d.h.
PRIMARY KEY (KeyField) WHERE NOT _DELETED ist kein zulässiges Sprachkonstrukt. Warum? Wenn das Bedigungsfeld geändert wird, könnte plötzlich ein Duplicate Key entstehen, ohne dass das Schlüsselfeld betroffen ist.
Normalerweise kommt der SQL Server mit einem Konsole-Programm, um manuell mit dem Server zu "spielen" (arbeiten). Darin kannst Du recht ungefährlich eine Spiel-Database anlegen und ausprobieren und eben auch sehen, wie der Server reagiert und welche Fehlermeldungen er von sich gibt.
Gerade MySQL ist das sehr "gesprächig", so dass Du ein entsprechendes Feedback bekommst (SQLite meldete sich eigentlich nur bei Fehlern).
Gruss,
Georg