Die Query-Werte sollten aufjedenfall den gleichen Datentyp wie von jener Spalte haben, damit keine Fehler passieren.
Ich kann dir zwei Möglichkeiten bieten:
1. Bei einem INSERT-Statement, setzt du nach dem INSERT-Keyword das Keyword "IGNORE" hinzu. bspw.: INSERT IGNORE INTO .. VALUES(...)

2. Du splittest deine Querys und führst jede einzeln aus ( zupft Performance ab, bei einer großen Anzahl von Querys )

Bei solchen Anfragen ist es sehr hilfreich, wenn angegeben wird, welche Datenbank verwendet wird.
Leider wird das meistens versäumt.
Wenn's ans Eingemachte geht, unterscheiden sich die SQL-Befehlssätze.

.prox schrieb:

INSERT IGNORE

ist MySQL-Dialekt.

@petaod, ich glaube, dass sehr wenige Entwickler den Datenbank-Funktiosnamen mit "MYSQL" beginnen, wenn sie nicht Mysql nutzen.

Klingt logisch.

ähm - bin ich der einzige, der solch hanebüchen findet?

Wohin führt das denn, wenn man so broadcast-mässig beliebigen Sql-Befehls-Müll an eine Db schicken kann?

Das in post#1 genannte Problem ist der Verstoß gegen eine Unique-Constraint, also ist so zu proggen, dass nicht gegen eine Constraint verstossen wird.

Naja, vlt. gibts Gründe, das ausnahmsweise doch zu tun, aber die müssen schon sehr stichhaltig sein.

Ach - und übrigens: Visual Studio - Empfohlene Einstellungen
Es ist inne OOP enorm wichtig, Datentypen zu respektieren, und dafür sollte man die Compiler-Unterstützung unbedingt aktivieren.

Insbesondere bei großen Datenmengen ist es halt performanter, die Constraint-Verletzung von der DB behandeln zu lassen.
Wenn sich ein Constraint über mehrere Spalten erstreckt und jedes Mal mit Select vorab geprüft werden soll, kostet das halt Zeit.
Bei Datasets, die vorher komplett ins Memory geladen werden können, lässt sich das in Single-User-Umgebungen auch vorab auf Programmebene prüfen.

Aber sobald Massendaten verarbeitet werden, ist es performanter, das von der DB erledigen zu lassen.

Und: Sobald mehrere Benutzer parallel arbeiten, lässt sich eine Constraint-Verletzung gar nicht zwingend vorab erkennen.

Jo, das mögen denkbare Gründe sein - aber liegen sie auch tatsächlich vor?

Und wenn man die Constraint-Verletzung nicht vorab erkennt, dann muss man sie halt erkennen, wenn sie auftritt, sei es durch TryCatch oder was weiß ich (ich weiss es wirklich nicht, ich fürchte, da wäre eine ungeheuer listige Update-Prozedur zu schreiben).
Aber einfach ignorieren kann und darf doch nicht die einzige, unhinterfragte Option sein.

---

@Uncle Ben's: Ich bin so frei und vermerke dich als einen, der die Visual Studio - Empfohlene Einstellungen zu tätigen vermutlich ablehnt.
Solch ist wichtig zu wissen, denn mit Strict-Off-Proggern kann man eiglich keine Programmier-Probleme wirklich angehen - die Basis besteht nicht, bzw. ist zu eingeschränkt.

---

Ups - ich sehe grad, dein Account ist gesperrt - na denn...