Frage - SQL Insert

  • Hallo zusammen,

    ich poste mein Anliegen einfach mal hier in Offtopic, da es denke ich nicht am Script liegt...

    ich hole mal aus... ich habe eine CSV-Datei, Semikolon-getrennt, in der ca 4.000 Kundendatensätze drin sind...

    Diese CSV-Datei ziehe ich mir mit Autoit und per Schleife und Stringsplit hole ich mir all diese Zeilen in jeweils in ein Array und fummel mir dann einen Insert-String zusammen damit ich diesen dann in eine mssql-db per _sql.au3 reinpumpen kann.

    Um den ganzen jetzt vorzugreifen... ich habe mir vorher ein SQL-File angelegt, in diesem SQL sind auch diese über 4.000 Inserts enthalten!!! Lade ich dieses SQL z.B. mit Heidi und lasse den Import laufen, erhalte ich nur etwas knapp über 1.600 Einträge in die Datenbank-Tabelle.

    Genauso verhält sich auch, wenn ich ohne SQL-File direkt in die Tabelle den Insert mit _SQL_Execute pumpen will... genau die selbe Anzahl an Datensätzen wie über Heidi.

    Da der Inhalt des SQL-Files ja die korrekte Anzahl enthält muss der Fehler also in der Tabelle liegen??? (hier ist kein Primärschlüssel oder sowas gesetzt).

    Hat jemand ne Glaskugel, was das sein könnte??? Ich bin für jede Idee dankbar...

  • ja das ist eine gute Idee... aber sollten sie nicht trotzdem geschrieben werden, weil ja kein Primarykey gesetzt ist? SQL würde Duplikate doch nur rausschmeißen, wenn ein Primarykey gesetzt ist oder bin ich auf dem Holzweg? :/

    Ich vergleiche einfach mal die Werte...

  • SQL würde Duplikate doch nur rausschmeißen, wenn ein Primarykey gesetzt ist oder bin ich auf dem Holzweg?

    Ich vermute, wenn du keinen PrimaryKey setzt, wird es auch keine Duplikate geben, sondern bereits vorhandene Einträge werden dann einfach überschrieben.

  • ch vermute, wenn du keinen PrimaryKey setzt, wird es auch keine Duplikate geben, sondern bereits vorhandene Einträge werden dann einfach überschrieben.

    Falls du Recht hast würde dies mein ganzes Verständnis zu SQL über den Haufen werfen. Ein kleiner Test mit _SQLite_GetTable2d.au3 zeigt mir es ist, zum meinem Glück, nicht so. Ohne Primarykey sind Duplikate erlaubt. Das Testskript ist ein Hilfebeispiel, abgeändert und erweitert um sich nicht die DLL herunterladen zu müssen. Dafür wird jetzt das Include benötigt: _SQLiteInline_X86.au3 oder die DLL muss auf anderem Weg zur Verfügung gestellt weden.

    Zum eigentlichen Problem vermute ich, das sich mit dem aufteilen der Datei in mundgerechte Häppchen (4 * 1/4 oder kleiner) der Schluckauf von Heidi verhindern lässt.

    mfg (auto)Bert

  • Könnte auch ein Unique-Constraint sein.

    Aber im Grunde bringt wildes Raten gar nix wenn du rein gar nichts zeigst.

    Stelle das Table-Statement der betreffenden Tabelle hier rein und zeig einen Ausschnitt (mit verschleiern der kritischen Daten) deiner Input-datei hier rein.

  • autoBert - ja, du hast Recht, meine Vermutung war falsch. AspirinJunkie hat es aber auf den Punkt gebracht...

    Edit: Wegen der mundgerechten Häppchen... da fällt mir gerade ein, dass ich so ein Problem auch mal hatte und dann die Inserts in kleinere Portionen zerlegt habe. Die zu konvertierende Datei words.txt (eng. Wörterbuch) enthielt 466544 Wörter mit unterschiedlicher Länge... und so in etwa habe ich es dann gemacht...

    Einmal editiert, zuletzt von Bitnugger (19. Juli 2018 um 17:19)

  • Zum eigentlichen Problem vermute ich, das sich mit dem aufteilen der Datei in mundgerechte Häppchen (4 * 1/4 oder kleiner) der Schluckauf von Heidi verhindern läss

    Aber um Heidi mal in Unschuld zu waschen, selbst mit einem direkten Insert in die Tabelle kriege ich genauso (viele/wenige) Datensätze rein wie mit Heidi... (stand ja schon im Erstellungsthread)

    Spoiler anzeigen

    Ich glaube ich werde mir was schreiben müssen, um herauszufinden ob der Datensatz auch geschrieben wurde, ich denke so komme ich eher dahinter was es ist... also den _SQL_Execute laufen lassen und dann mit ner Query count(*) prüfen ob er da ist?!

    Oder gibts da was besseres? Select auf den Datensatz, wenn Count > 0 dann ist er da?!

    Ich war beim Anlegen der Tabelle sehr kreativ...

    Spoiler anzeigen

    Trotzdem muss ich erstmal herausbekommen welcher Datensatz NICHT geschrieben wird, damit ich mir diesen und einen der funktioniert vergleichen kann...

  • Aber um Heidi mal in Unschuld zu waschen, selbst mit einem direkten Insert in die Tabelle kriege ich genauso (viele/wenige) Datensätze rein wie mit Heidi... (stand ja schon im Erstellungsthread)

    Ja, da hast du geschrieben...

    Genauso verhält sich auch, wenn ich ohne SQL-File direkt in die Tabelle den Insert mit _SQL_Execute pumpen will... genau die selbe Anzahl an Datensätzen wie über Heidi.

    ...was den Schluss nahelegt, dass du bei beiden Vorgehensweisen denselben Fehler machst. Ich denke, alpines hat darauf bereits die richtige Antwort geliefert.

    Probier sie doch mal Schritt für Schritt einzusetzen und schau welchen Eintrag er nicht reinschreibt, vielleicht sind diese ja schlecht formatiert?

  • Aber um Heidi mal in Unschuld zu waschen, selbst mit einem direkten Insert in die Tabelle kriege ich genauso (viele/wenige) Datensätze rein wie mit Heidi... (stand ja schon im Erstellungsthread)

    Hast du es denn in Teilpaketen getestet? Könnte ja immerhin sein, daß der Eingabepuffer eine max. Größe hat.

    Aber:

    Aber im Grunde bringt wildes Raten gar nix wenn du rein gar nichts zeigst.


    Stelle das Table-Statement der betreffenden Tabelle hier rein und zeig einen Ausschnitt (mit verschleiern der kritischen Daten) deiner Input-datei hier rein.

    obiger Aufforderung solltest du einfach einmal nachkommen, damit die Kaffesatzleserei ein Ende hat.

    mfg (auto)Bert