THEMA:

Hallo,

ich habe eine Frage:

Ich möchte in eine leere SQL-Tabelle
Sätze aus einer bestehenden SQL-Tabelle kopieren
und dabei bestimmte Sätze aus-filtern.

In der Quell-Tabelle (Messwerte zu einer Auftrags-Nr.)
ist notwendigerweise das Feld Datum ein Key-Feld.
Das liegt daran, dass es vorkommen kann, dass zu einer
Auftrags-Nr. eine Mess-Reihe mehrfach ausgeführt wird.
Es SOLLEN dann auch wirklich ALLE Mess-Reihen GESPEICHERT WERDEN (also : 1-n zu einer Auftrags-Nr.)

Durch Bediener-Fehler am Erfassungs-Terminal
( bzw. mangelhafte Qualität der Erfassungs-Software
an der messenden Maschine )
wurden nun jedoch hunderte Sätze doppelt erfasst ...
( z.B.: 2x ENTER für drucken+speichern gedrückt, und schon gibt es zwei identische Mess-Wert-Datensätze,
die sich ja aber in der Uhrzeit (Datum) unterscheiden,
beim Import ist das also jeweils ein NEUER SATZ. )

Meine Idee war, in einer (neu angelegten) Ziel-Tabelle das Feld Datum NICHT als Teil des Keys zu benutzen, sondern
eine Kombination hinreichend vieler anderer Felder,
die sicher stellen, daß es sich
bei kompletter Übereinstimmung dieser Felder
um ein und dieselbe Messreihe handeln muss.
(Einstellung Adapter = INSERT + vorhandene ignorieren)
So funktioniert es aber leider nicht.

Offensichtlich wird nur Satz für Satz kontrolliert,
ob der jeweils aktuell zu importierende Satz
VOR DEM IMPORT bereits in der Tabelle vorhanden war,
und nicht, ob dieser Satz
im Rahmen des LAUFENDEN Imports bereits eingefügt wurde.

Das heisst: Auch wenn alle Key-Felder aus Satz 2
mit denen von Satz 1 identisch sind,
wird Satz 2 nicht ignoriert, sondern eingefügt.

Also lautet meine Frage:
Wie kann ich mir einen Filter definieren,
der den LAUFENDEN INSERT checkt ?
Geht das überhaupt ?
Es müsste ja bei jedem einzufügenden Satz
der komplette Clustered-Key (8 Felder)
abgeglichen werden ...
und das mit allen den Sätzen,
die bereits zum INSERT freigegeben sind ...

aber wenn das ginge ... wäre schon toll ...



Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Hallo Reiner,

Um das abzubilden gibt es 4 Möglichkeiten.

1) Über den Primary Key der Tabelle:
Dein Ansatz mit (Insert + vorhandenen Datensätze ignorieren) war/ist schon richtig gewesen. Ich vermute mal du hast im Primary Key zusätzlich noch einen AutoWert oder ein Datumsfeld mit Sekunden oder so. In diesem Fall ist der gerade bearbeitete Datensatz natürlich unterschiedlich und wird wiederum in die Tabelle geschrieben. Sollte der Datensatz gleich sein, würde die Datenbank bei einem weiteren Insert/Import einen Fehler melden.

Du kannst auf der WRITE Seite im Configurator für den Datenbank Adapter die Felder auswählen anhand der FlowHeater Updates vornimmt bzw. prüft ob der Datensatz bereits existiert. Beim einlesen des Schemas der Tabelle sind das automatisch die Primary Key Felder. Diese können nach dem einlesen geändert werden. Bitte prüfe das nochmal und entferne einfach die Hacken für Primary Key bei den nicht gewünschten Feldern bzw. füge weitere hinzu, das ganze sollte eigentlich klappen.

2) Über eine Gruppierung:
Auf der READ Seite sortierst du die Datenquelle anhand der Felder die für dich dem Kriterium entsprechen dass der Datensatz gleich ist.

select * from deinetabelle order by feld1, feld2, …

Diese Felder ziehst du dann in der Definition alle auf einen GroupBy Heater. Hiermit werden bereits alle gleichen Datensätze auf der READ Seite zu einem Datensatz zusammengefasst, an der WRITE Seite kommt dann lediglich ein SQL Insert an. Dies hat bei großen Datenmengen den Vorteil, dass nicht (massenhaft) unnötig geprüft werden muss ob der Datensatz bereits existiert.

WICHTIG: Für eine Gruppierung im FlowHeater muss die Datenquelle sortiert sein! Sollte die Datenquelle keine Sortierung unterstützen, kannst du dafür auch den Sort Heater verwenden.

3) Über den Lookup Heater:
Hiermit kannst du dir ein (am besten immer gefülltes) Feld aus der WRITE Datenquelle zurückliefern lassen. Als Kriterium musst du wiederum alle Felder, anhand du den Datensatz identifizierst auf den Lookup Heater ziehen und eine SQL Where Klausel bilden. Den so zurückgelieferten Wert prüft du über einen IF-THEN-ELSE auf ungleich NULL, das Ergebnis dieser Prüfung muss dann noch mit dem Filter Heater verbunden werden.

Hiermit werden diejenigen Datensätze gefiltert/übersprungen, bei denen die Bedingung:
Wert vom Lookup Heater ungleich NULL = TRUE bzw. WAHR = Datensatz wird gefiltert.

4) Über den .NET Script Heater:
Ähnliches Vorgehen wie bei 3, nur können hiermit wesentlich komplexere SQL Statements gebildet und abgesetzt werden. Hierzu wird es demnächst ein eigenes Beispiel geben.



Ich würde dir die Lösung 2) vorschlagen. Ist am einfachsten zu implementieren sowie Performance technisch am günstigsten.

Hoffe damit weitergeholfen zu haben!

Danke für die schnelle Reaktion.

Methode 1 funktoniert offensichtlich doch so wie ich es zunächst probiert hatte.

Vielleicht habe ich mich da gestern versehen, ich meine jedoch, dass ich in der Ergebnis-Anzeige des Testlaufs
nur INSERTS gesehen hatte und kein einziges IGNORED.

Beim realen Einfügen der Daten tauchen nun jedenfalls
die erwarteten IGNOREDs doch im Protokoll auf ...

Wie auch immer, das "Aus-Filtern" der Datensätze funktioniert jetzt jedenfalls wie gewünscht. Prima.

... und nochmal vielen Dank