Feld darf nur einmal vorkommen

[Hansa]

Ja, bin doch blind. 8) Aber es gibt noch ein Problem: trotz leerer Tabelle kommt diese Fehlermeldung :

Zitat:

Zitat von IBExpert

Invalid insert or update value(s): object columns are
constrained - no 2 table rows can have duplicate column values.
attempt to store duplicate value (visible to active transactions) in unique index "RDB$48".

Wenn ich nur die Nr. nehme. Packe ich die ID noch dabei, dann geht es auch. Wo finde ich jetzt, was RDB$48 genau ist ?

[DelphiDeveloper]

das ist der interne RDB$Indexname

findest du in Tabelle RDB$Indices

[Robert_G]

Schreibe mal ein INSERT per Hand.
Ich denke mal du kannst die Werte mit einem anderen Programm noch nicht sehen, weil die Transaktion nnoch nicht abgeschlossen ist. Es ist aber möglich, dass in deiner Anwendung 2 INSERTs abgesetzt worden.
Wenn dein INSERT "zu Fuss" klappt, dann hast du einen Fehler in der Anwendung (du schreibst 2-mal).

[Hansa]

select * from RDB$INDICES

Dann werden die RDB$RELATION-NAMES aufgeführt unter anderem auch RDB$INDICES. Aber nichts zu sehen von RDB$48

[Leuselator]

Moin Hansa,

ZU: "was hat das mit mit alphanumerisch zu tun?"
Alphafelder als primary verlangsamen den Zugriff und machen Dir das Leben im Programm schwerer - prinzipiell geht es schon, aber wer nimmt schon die Säge, um einen Nagel in die Wand zu schlagen? :mrgreen:

ZU: "Uniqueproblem"
Wenn Du etwa alt-Datensätze nicht löschst, sondern nur deaktivierst und beim Update statt Update tatsächlich den Altsatz deaktivierst und einen neuen einfügst (um z.B. die Tabelle zu historisieren, also alle Änderungen im Nachhinein nachvollziehbar zu machen), fällst Du natürlich mit dem Unique-Index in der Tabelle auf die Nase, da die Kd-Nummer im Altsatz schon drinn ist, kann der Neusatz nicht eingefügt werden. Wenn das Problem aus der Ecke daherkommt, dann lager die KdNummer in eine Lookuptabelle aus (Fields: (Id Int) und (KdNummer alpha unique)) und speicher in der eigentlichen nur die Id der Kundennummer - dann bist Du das Problem los.

Hoffe das hüleft
Gruß

[Hansa]

Zitat:

Zitat von Leuselator

...aber wer nimmt schon die Säge, um einen Nagel in die Wand zu schlagen?

Das geht schon ! z.B. mit der "Rückseite" einer Metallsäge. :lol:

Jetzt wirfst Du allerdings einen völlig neuen Aspekt auf, mit der Historie etc. Mit dem zusammengesetzten key wäre das tatsächlich relativ einfach zu machen. Im Moment aber egal.

Ihr macht es aber jetzt immer noch zu kompliziert. Die ID ist der primary key. Die Nr. ist ein integer. Da ich bisher aber keinerlei Performance-Probleme festgestellt habe, sind die Indices vorerst auch mal noch außer Acht gelassen. Die Test-DB hat allerdings nur ca. 30 MB und ist lokal.

Aus Versehen habe ich nun einen Kunden mit derselben Nr. eines bestehenden angelegt. Und das muß ich eben abfangen. Sonst nichts.

[Robert_G]

Wenn die Kunden Nr. numerisch ist, dann schmeiß' die ID weg und mache die Kunden Nr. zum prim. Key.
Färtisch!

[Hansa]

1. Was habt ihr nur mit dem numerisch/alphanummerisch ? Inwiefern spielt das eine Rolle ?

2. wie wirkt sich aus, welches Feld den Primary Key hat ?

3. Das hier funktioniert :

ALTER TABLE KG ADD CONSTRAINT NQ_KG UNIQUE (NR);
ALTER TABLE KG ADD PRIMARY KEY (ID);

Wenn ich den primary key von ID auf NR lege und den UNIQUE entferne, was ist dann (siehe auch 2) ?

Bei der Kundentable kommt aber eine Fehlermeldung (siehe weiter oben).

[Delphi_Fanatic]

Wieso machst Du es nicht einfach so, dass Du in Deinem BeforPost Event mit der SQL-Funktion (Max) den
höchsten Wert Deiner Primary-Key-Spalte ermittelst, einen drauf addierst, und dann den Wert als neuen
Primary-Key abspeicherst ?

So kannst Du Dir doch auf recht simple Weise einen eindeutigen Primary-Key selbst erzeugen.

Wenn Du Dir von der Datenbank irgendwelche Primary-Keys erstellen lässt (wie z.B. mit diesem
Typ 'AutoWert' bei MSAccess), dann bist Du mit Deiner Anwendung auch fest an diese Datenbank
gebunden und kannst nicht so einfach irgendwann mal auf eine andere Datenbank umsteigen.

Wenn Du Dir dagegen selber den Primary-Key erstellst, dann könntest Du Deine Anwendung recht leicht
von der Benutzung einer DB (wie z.B. Access) auf eine andere DB (wie z.B. SQL-Server oder meinetwegen
IB) 'umschalten'.

P.S. und natürlich müßtest Du vor diese Sache mit der Primär-Key-Erstellung eine if-Abfrage setzten,
mit der Du sicherstellts, dass der Primär-Key auch nur dann erstellt wird, wenn er noch nicht vorhanden
ist . (also nur nach einem Insert, und nicht nach jedem Edit => Post).

[Robert_G]

Das ist doch sinnlos.
Erstens hat es Hansa mit einer DB zu tun (er hat kein Access und Co.), deshalb kann er einen neuen Datensatz an den Server schicken und der generiert innerhalb der DB einen neuen Schlüssel.
Dieses Abfragen, hochzählen und dann erst Abschicken widerspricht doch komplett dem Konzept von stored procedures!