INSERT INTO ohne Duplikate

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von SchorschCode.

    INSERT INTO ohne Duplikate

    Hallo zusammen,

    ich lese Daten aus einer Textdatei und möchte Teile davon in eine MSSQL-Tabelle schreiben. Leider finde ich die korrekte Syntax nicht. Dieser Befehl funktioniert nicht:

    VB.NET-Quellcode

    1. INSERT INTO tblArtikel(ARTNR) VALUES ("4711") WHERE "4711" NOT IN (SELECT ARTNR FROM tblArtikel)


    Fehler: Falsche Syntax in der Nähe des WHERE-Schlüsselwortes.

    Der Datensatz soll also nur angelegt werden, wenn die Artikelnummer 4711 noch nicht vorhanden ist.

    Kann mir jemand sagen, wie die korrekte Synatx für den Befehl lautet?

    Danke im voraus!
    Es gibt kein INSERT INTO ... WHERE lediglich ein INSERT INTO ... SELECT dabei befüllst du jedoch die Tabelle mit Daten aus einer anderen Tabelle.

    Wenn es in der Tabelle nicht zu häufigen Änderungen kommt, würde ich beim Start der Anwendung alle ARTNR holen, und dann mit dem Einlesen der Datei beginnen, und dabei Zeile für Zeile die Daten in die Datenbank übertragen.
    Für MSSQL müsste auch das funktionieren:

    SQL-Abfrage

    1. ​if not exists (select ARTNR from tblArtikel where ARTNR=4711) insert into tblArtikel VALUES(4711)

    Aber wenn du keine MultiUser-Anwendung hast, würde ich so eine Tabelle auch im Programm cachen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Danke für Eure Antworten. Es handelt sich um eine Tabelle mit 1.500.000 Datensätzen, da ist das Öffnen, Lesen und Updaten viel zu langsam.

    Es ist keine Multiuser-Anwendung, das Öffnen dauert ca. 1 Minute, der Update über 5 Minuten. Da werden teilweise 300 Dateien eingelesen, jedesmal öffnen, lesen, speichern - das dauert...

    Ich werde petaods Lösungsansatz probieren und berichten.
    Was spricht dagegen ArtNr einfach als Primary Key (bzw. zumindest unique) zu kennzeichen? Oder was genau repräsentiert die Tabelle denn? Eine Entity? Eine Relation? Dann könntest Du z. B. INSERT IGNORE benutzen.
    Ansonsten könnte man sicher noch mit Constraints oder irgendwelchen Triggern rumspielen, aber das ist wohl eher overkill.

    Edit: Ach, MSSQL. Habe mich verlesen, sorry.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Trade“ ()

    @petaod: Herzlichen Dank! Läuft wie ein Länderspiel.

    Ich habe lange nach der Lösung gesucht; hast mir sehr geholfen!!!

    @trade: Die Aufgabe ist eigentlich ganz einfach: Textdatei einlesen, nachschauen ob der Datensatz schon da ist, und wenn nicht, in die Tabelle schreiben.

    Aber bei der Menge an Daten wirds mit den von mir benutzen Mitteln zu langsam (Öffnen, Lesen, Aktualisieren). Deshalb die Idee mit dem SQL-Befehl.

    Danke auch an Dich für Deine Antwort! Ich glaube, ich sollte mich etwas intensiver mit der SQL-Syntax beschäftigen. Auch mit Triggern und Constraints kenne ich mich gar nicht aus; soll sich jetzt ändern!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „SchorschCode“ ()

    SchorschCode schrieb:

    Läuft wie ein Länderspiel
    Wenn ich auf die letzten Fußballländerspiele zurückblicke:
    Alles sehr schleppend und langsam.
    Die meisten Versuche scheitern oder enden mit falschem Ergebnis.
    Mittendrin geht für eine Viertelstunde überhaupt nichts.
    Du kannst nur verlieren.

    Ich hoffe, dein Programm läuft besser,
    :D
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Alles sehr schleppend und langsam.


    Oh, ich dachte da an Frankreich (blöde Ausrede...).

    Mal im Ernst: die 540.000 Datensätze werden jetzt in ca. 10 Minuten angelegt, vorher brauchte das Programm ca. 30 Minuten. Vor dem INSERT erfolgt auch noch ein UPDATE, falls ein Datensatz schon vorhanden sein sollte. Schneller gehts wohl nicht.

    Danke nochmal!