In meinem SQL Server 2014 habe ich eine Tabelle mit einer varchar
/ (beide getestet, das Ergebnis ist die gleiche!) Spalte, die der Primärschlüssel ist. Tatsächlich müssen die Spaltenwerte eindeutig sein und werden für ungefähr 50% der Auswahlen verwendet, so dass es sinnvoll erscheint, sie zum PK zu machen. Die Spalte wird jetzt auf Collation <database default>
gesetzt, die Latin1_General_AS sein sollte, nicht sicher, ob Sortierung hier das Problem ist.SQL Server-Schlüssel und Vergleich
In dieser varchar Spalte I einen Wert mit Sonderzeichen einzufügen, in diesem Beispiel der polnischen Osioł
(aber ich möchte alle Zeichen unterstützen, die in LDAP CN Namen in Zukunft erlaubt) (?):
INSERT INTO Names (Name, Mail) VALUE('Osioł', '[email protected]');
Wenn ich jetzt versuchen, diesen Wert zu aktualisieren:
UPDATE Names SET Mail='[email protected]' WHERE Name='Osioł';
es gibt Null zurück geänderten Zeilen. Was für mich bisher bedeutete, dass der Schlüssel noch nicht benutzt wird und ich einfügen kann. Was ich später versuche und mit dem Fehler
fehlschlägt Verletzung der PRIMARY KEY-Einschränkung 'PK_Names'. Kann keinen doppelten Schlüssel im Objekt 'dbo.Names' einfügen. Der doppelte Schlüsselwert ist Osioł.
Das gleiche gilt für Selects:
SELECT * FROM Names WHERE Name='Osioł';
nicht die Zeile zurück.
Wie kann ich diese Zeile mit dem PK mit speziellen Zeichen auswählen/aktualisieren?
von den Blicken von ihm Sie auf dieser Tabelle einen Primärschlüssel haben und dieser Datensatz bereits vorhanden . Versuchen Sie, die Definition der PRIMARY KEY-Einschränkung zu finden, um das Problem einzugrenzen und den Datensatz zu finden, der die Beschwerde verursacht. –
auch INSERT INTO Namen (Name, Mail) VALUE ('Osioł', '[email protected]'); sollte INSERT IN NAME (Name, Mail) VALUES ('Osioł', '[email protected]'); –
Ich würde auch vorschlagen, dass weder Name noch E-Mail einen guten Primärschlüssel bilden. Namen sind nicht garantiert eindeutig und E-Mails sind einzigartig, können aber von verschiedenen Personen wiederverwendet werden und ändern sich häufig. Die Namen haben sich ebenfalls geändert und ein PK sollte etwas sein, das sich nicht ändern sollte, besonders wenn Sie untergeordnete Tabellen verwenden, die FK verwenden. Sie sollten ein Auto-Nummernfeld als PK haben (es wird auch schneller in Joins funktionieren) und einen eindeutigen Index für E-Mails sowie einen regulären Index für den Namen. – HLGEM