Datensätze schnell einfügen bzw. ersetzen

[Dejan Vu]

Zitat:

Zitat von messie (Beitrag 1260153)

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.

[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.

[messie]

Zitat:

Zitat von Dejan Vu (Beitrag 1260155)

Zitat:

Zitat von messie (Beitrag 1260153)

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.

[jobo]

Zitat:

Zitat von messie (Beitrag 1260162)

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

Ich kenne keine Clientkomponenten, mit denen mehrere Befehle als Script abgesetzt
werden können. Was nicht bedeutet, dass es sie nicht gibt.
Einziges mir bekanntes Verfahren ist die Verwendung eines anonymen Blocks, in dem (größenbeschränkt) mehrere Statements hintereinander verarbeitet werden können.
Das geht aber nur bei bestimmten RDBMS, die das unterstützen und Parameter zu verwenden wird schwierig.

Zitat:

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

Wenn Du satzweise matching durchführst, muss das System für jeden Satz einzeln die gesamte Tabelle nach den Parametern scannen, ggF. mangels Index sogar per Fullscan.
Wenn es Dir zu langsam ist, prüf die Indizierung Deiner Parameter Spalten (Achtung Begriffe: Index<>Fremdschlüssel Constraint) oder schau Dir noch mal meinen Vorschlag an, alles in 2 Schritten zu machen.

[messie]

Moin,

das Update mit Parametern dauert jetzt eine halbe Stunde und ist erst zu einem Drittel fertig. Da muss wohl eine Tabellenlösung her.
@jobo: hast Du da ein etwas konkreteres Beispiel für mich?

Danke, Messie

[jobo]

Zitat:

Zitat von messie (Beitrag 1260165)

st erst zu einem Drittel fertig. Da muss wohl eine Tabellenlösung her.
@jobo: hast Du da ein etwas konkreteres Beispiel für mich?

"etwas konkreter" ist ja dehnbar. ;)

also hier mein Vorschlag von oben:

Zitat:

* 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

konkreter:
1. CSV Import über externes File wie z.B. hier nach Tabelle 'Neudat<en':
http://www.delphipraxis.net/180125-w...-firebird.html

2. korreliertes Update des Bestandes
über deine 3(?) Parameter

Code:

UPDATE Bestandsdaten
   SET <column> = N.<NewColumn>
            ..
   FROM bestandsdaten AS B INNER JOIN Neudaten As N
   On B.NR = N.NR ...

3. Delete der NeuDaten, die bereits für Update verwendet wurden.
Statement (vor allem Join) wie oben nur eben delete

4. Insert der Restdaten

Code:

insert into Bestandsdaten <columns>
select <columns> from Neudaten

5. Leeren der restlichen Neudaten

Code:

delete / truncate Neudaten

So mal als Idee. Kann man ausbauen oder abändern, wenn man mehr Kontrolle braucht.
z.B. "sind meine 3 Parameter eindeutig?", ...
Wenn man beim Bestand unsicher ist, ob die Kriterien hinreichend sind, kann man z.B. auf das Delete (Step3) verzichten, das Insert komplexer abgleichen und damit die gesamte Tabelle "Neudaten" für Prüfungen bewahren.
Ist man nicht sicher, dass die Eindeutigkeit der Neudaten über die gewünschten Kriterien gegeben ist, kann nach dem Import erstmal Prüfstatements drüberlaufen lassen.

[messie]

Moin,

ich habe das Problem jetzt aufgeteilt. Es gibt zwei Situationen, das nachträgliche händische Ändern von Messwerten und den Datenimport. Letzterer ist einmalig, also nicht ganz so wichtig. Da muss ich dann eben warten.
Bei den nachträglich geänderten Werten hole ich mit jetzt die Daten in eine Query und vergleiche den Messwert mit dem neuen Wert im Array. So muss ich nur auf der DB schreiben wenn sich die Werte tatsächlich geändert haben. Und da man in dieser Situation eher nur wenige Werte ändert, ist das kein Problem bei der Performance mehr.

Danke für die Unterstützung :thumb:

Grüße, Messie

[messie]

Ätsch, so schnell kann es gehen :oops:
Ich habe jetzt doch zwei andere Stellen wo ich ein paar tausend Datensätze auf einmal einfügen muss.
Daher zuerst die Frage für die Update or Insert-Variante: wie bekomme ich den vom Trigger angelegten Index des Datensatzes im returning zurück? Das Feld ID wird mir verweigert.

Grüße, Messie

[mkinzler]

Bei IBDAC wird dieser in dem Parameter RET_ID zurückgegeben.

[messie]

Zitat:

Zitat von mkinzler (Beitrag 1260331)

Bei IBDAC wird dieser in dem Parameter RET_ID zurückgegeben.

Danke!:thumb:

Noch ein komischer Fehler:

Code:

UPDATE OR INSERT INTO table (P_ID,ST_NO,MEASUREMENTS)  VALUES(:P_ID,:ST_NO,:MEASUREMENTS) MATCHING (P_ID,ST_NO) returning RET_ID into :ID;

wirft mir einen Fehler "unexpected end of command line" an am Komma zwischen den beiden matching-Spalten. Ohne returning läuft es problemlos durch.

Grüße, Messie

Edit: wenn ich kürzere Variablen verwende, bleibt das Problem an derselben Spalte.