Datensätze schnell einfügen bzw. ersetzen

[messie]

Zitat von Perlsau:

Wäre es zuviel verlangt, einfach mal den Code deiner Tabellenstruktur hier zu posten? Sonst kann ich nicht erkennen, ob du nicht schon beim Erstellen der Tabelle bereits Fehler gemacht hast. Oder ist das geheim

Ja, das ist geheim und nein, ich habe keine Fehler gemacht

Ich habe nun den von mir bevorzugten Ansatz mal getestet und bekomme meine Änderungen tatsächlich zusätzlich als Eintrag in die entsprechende DB. Ein ganzer Haufen redundanter IDs
Aber es war sehr schnell trotz der großen Anzahl von Datensätzen

Ich habe gelernt, dass ich in manchen Themen gerne mal völlig betriebsblind bin. Ich sehe bisher keine Möglichkeit, in einem Rutsch ein paar tausend Datensätze in ein paar Sekunden zu implantieren. Das ist aber eine Kernaufgabe die ich zu lösen habe.

Danke, Messie

[jobo]

Ein paar Gedanken dazu:

* Primärschlüssel, technische (automatisch generiert) helfen Dir nicht beim Existenzabgleich, denn die einzufügenden Daten besitzen diesen eindeutigen aber "zufälligen" Schlüssel nicht.

*"ein paar tausend Datensätze"
bekommst Du tatsächlich sehr schnell über externe Tabellen in die DB

* da empfiehlt sich ggF eine extra Importtabelle fürs Laden (alles rein, ohne Abgleich)

* im 2. Schritt dann die erwähnten Merges / Update or Insert Statements und zwar nicht Satz für Satz, sondern die komplette Zwischentabelle in einem Rutsch. Abgleich über fachliche Schlüsselfelder, ggf mehrere

[messie]

Moin,

ich habe jetzt eine Update or Insert-Liste erstellt wie vorgeschlagen. Ich scheitere derzeit aber an der Übergabe im Programm:

Code:

DM.Query2.SQL.Add('UPDATE OR INSERT INTO ' + MDATA + '(TIME_STAMP,PUMP_STEP_ID,MEASUREMENT_INDEX,MEASURED_VALUE,TIMESTAMP_VALUE) ' +
            'values(' + QuotedStr(TimeStamp) + ',' + QuotedStr(IntToStr(DBindex)) + ',' +
            QuotedStr(IntToStr(mid)) + ',' + QuotedStr(FormatFloatNow('#0.00000', MValues[mid])) + ',' +
            QuotedStr(ts) + ') matching (TIME_STAMP,PUMP_STEP_ID,MEASUREMENT_INDEX);' );

Wenn ich den Inhalt von SQL in eine Datei speichere und in Flamerobin einfüge klappt das ohne Probleme.
Was habe ich da übersehen?

Danke, Messie

[Dejan Vu]

Nimm doch erst einmal Parameter.

[messie]

Zitat von Dejan Vu:

Nimm doch erst einmal Parameter.

Moin,
verstehe ich nicht
Kann ich die returning-Klausel nicht weglassen? Was macht Flamerobin da anders?

Code:

update or insert into Cows (Name, Number, Location)
  values ('Suzy Creamcheese', 3278823, 'Green Pastures')
  matching (Number)

Grüße, Messie

[mkinzler]

Warum verwendet ihr immer .Add wenn ihr den Inhalt ersetzen wollt? :gruebel
Verwende besser (SQL-)Parameter!

Delphi-Quellcode:

DM.Query2.SQL.Text := 'UPDATE OR INSERT INTO ' + MDATA + '(TIME_STAMP,PUMP_STEP_ID,MEASUREMENT_INDEX,MEASURED_VALUE,TIMESTAMP_VALUE) ' +
            'values(':TIME_STAMP, :PUMP_STEP_ID, :MEASUREMENT_INDEX, :MEASURED_VALUE, :TIMESTAMP_VALUE);';
...
DM.Query2.ParamByName( 'TIME_STAMP).Value := TimeStamp;
...

[messie]

Zitat von mkinzler:

Warum verwendet ihr immer .Add wenn ihr den Inhalt ersetzen wollt? :gruebel
Verwende besser (SQL-)Parameter!

Delphi-Quellcode:

DM.Query2.SQL.Text := 'UPDATE OR INSERT INTO ' + MDATA + '(TIME_STAMP,PUMP_STEP_ID,MEASUREMENT_INDEX,MEASURED_VALUE,TIMESTAMP_VALUE) ' +
            'values(':TIME_STAMP, :PUMP_STEP_ID, :MEASUREMENT_INDEX, :MEASURED_VALUE, :TIMESTAMP_VALUE);';
...
DM.Query2.ParamByName( 'TIME_STAMP).Value := TimeStamp;
...

Add benutze ich weil ich ein paar tausend Werte ersetzen muss und das ExecSQL aus Geschwindigkeitsgründen nicht mit jeder Übergabe haben möchte. Nach meiner Auffassung und den obigen Beispielen muss ich doch nach jeder Übergabe das ExecSQL ausführen oder wird jede Parameterübergabe in den Cache geschrieben?
Was ist denn an meinem Statement falsch, dass es mit IBDAC nicht klappt aber in Flamerobin?

Grüße, Messie

[Dejan Vu]

Zitat von messie:

Was ist denn an meinem Statement falsch, dass es mit IBDAC nicht klappt aber in Flamerobin?

Geraten: Im Flamerobin ist eine andere Formatierung eingestellt (Datumsformat, Zahlen etc.) als in IBDAC. Daher der Rat, Parameter zu verwenden, denn dann werden die Werteformatierungen vom Provider vorgenommen, der vorher das RDBMS gefragt hat, wie die Parameter denn auszusehen haben.

[messie]

Zitat von Dejan Vu:

Zitat von messie:

Was ist denn an meinem Statement falsch, dass es mit IBDAC nicht klappt aber in Flamerobin?

Geraten: Im Flamerobin ist eine andere Formatierung eingestellt (Datumsformat, Zahlen etc.) als in IBDAC. Daher der Rat, Parameter zu verwenden, denn dann werden die Werteformatierungen vom Provider vorgenommen, der vorher das RDBMS gefragt hat, wie die Parameter denn auszusehen haben.

Nee, scheint am falschen Abschluss der Zeilen zu liegen. Einzeilige Befehle gehen ohne Fehler, bei mehrzeiligen Befehlen hakt es am Beginn der zweiten Spalte.

Allgemein habe ich noch nicht kapiert, wie ich mit den Parametern das matching ersetzen soll. Ich habe drei Parameter, aus denen sich ein Datensatz eindeutig erkennen lässt.
Eingentlich brauche ich dann mit Parametern doch auch ein matching oder liege ich da falsch?

Grüße, Messie

Edit: klappt gut mit dem matching aber ist ziemlich langsam trotz autocommit=false und cachedupdate=true.

[mkinzler]

Gerade dann bieten sich Parameter ja an. Die Abfrage brauchst du nur einmal setzen und dann nur noch die Parameter, es werden dann nur noch diese an das DBMS übertragen, Auch bei vollständigem Setzen der Abfrage musst sDu diese per ExecuteSQL senden.