HelgeLange - Fr 08.06.07 14:52
Titel: Seltsamer Fehler beim INSERT

---

Ich kämpfe seit Tagen in der Firma, in welcher ich arbeite, mit einem seltsamen Fehler.
Wenn ich auf eine LEERE Tabelle mit Primary Key ein Insert machen will, bekomme ich den Fehler, dass eine Verleztung des primary keys aufgetreten ist und der insert nicht ausgeführt werden kann. In der Konsole klappt es. Als Komponenten benutze ich SQLDirect 5.x

Irgendwelche Ideen?
Oder andere Komponenten im Sinn ?

UGrohne - Fr 08.06.07 15:14

---

Wie fügst Du diesen neuen Datensat ein? Per SQL? Ich bin nicht so ganz firm mit SQLServer (bisher), muss bei einem Primary Key dann nicht eine Art Trigger laufen, wenn Du sie über die Datenbank vergeben willst?

HelgeLange - Fr 08.06.07 17:28

---

naja, es ist eher so, dass ich per SQL den Primary mit vergebe (liegt daran, dass die Daten aus XML importiert werden und die die Keys schon haben).
Die Sache ist dann die, dass ich diese Verletzung auch bekomme, wenn ich den 1. Datensatz in die Tabelle einfüge, die frisch erstellt wurde.

UGrohne - Fr 08.06.07 17:44

---

Dann zeig mal das SQL-Statement, das Tabellen-DDF und ein wenig Code. Das muss dann aber jemand anders weiter übernehmen, weil ich jetzt los muss und erst Sonntag wiederkomme ;)

HelgeLange - Fr 08.06.07 19:37

---

Naja, wie gesagt, der INSERT-Befehl funktioniert in der Konsole bei der Tabelle. Mit den gleichen Daten (Copy-Paste vom Delphi-Variable-Watch), aber im Programm bringt er den Fehler, dass der primary Key verletzt wird, obwohl es

a) in der Konsole geht mit den Daten
b) die Tabelle eh leer ist

:?

BenBE - Sa 09.06.07 11:35

---

Hab mit dem SQLServer bisher noch nicht gearbeitet; daher nur ne Vermutung):

Versuch mal eine Aufsplittung in zwei Befehle, indem Du im Insert für den PK NULL übergibst und dann über ein UPDATE den PK auf den gewünschten Wert setzt. Den AutoInc-Wert (sofern verwendet) sollstest Du über INSERT_ID (oder wie das hieß) rausbekommen.

Ferner: Hast Du auf der Tabelle ForeignKeys? Wenn ja: Existieren die dafür benötigten Daten bereits? (ggf. mit Defered Insert arbeiten???)

HTH.

Ralf Jansen - Sa 09.06.07 12:52

---

Schau dir mal im Profiler vom SQL Server an wie das SQL aussieht das wirklich an den Server gesendet wird.
Vielleicht gibt dir das einen Anhaltspunkt was schiefgeht.

Warum benutzt du eine Third Party Bibliothek für den Zugriff? Warum nicht einfach ADO(ist die nativste Möglichkeit für den SQL Server)?

HelgeLange - Sa 09.06.07 14:14

---

PK darf nicht NULL sein (sind 3 Felder zusammen, die den PK ergeben), sonst finden wir die ja ned wieder. Wir reden hier auch von einer Tabelle mit mehreren hunderttausend Datensätzen (im live-system).

ADO nutze ich nicht, weil ich mich an die Vorgaben des Arbeitgebers halten muss und am bestehenden System entwickeln. Wenn es garnicht geht, kann ich immernoch wechseln. Aber zur Zeit muss ich es mit den 3rd party probieren. Nur leider haben wir dafür keinen Source :(

HelgeLange - Mo 11.06.07 16:39

---

Also ich habe jetzt testweise mal auf die Komponenten von CRLab (SDAC) umgestellt und mit denen kommt der Fehler nicht. Also nehme ich mal an, es liegt einfach an den doofen SQL Direct Komponenten.

Ausserdem werden wir die CRLab Komps kaufen, denn zusätzlich zum Fakt, dass sie offensichtlich funktionieren, sind sie ausserdem VIEL schneller. Ein Programm, welches mit den SQLDirect komps ca. 30 min zur Ausführung brauchte, braucht jetzt 2 Minuten. Selber Code, nur Zugriffskomps getauscht...