2. Dataset in dem Daten aus 1. Dataset ausgeschlossen sind (not in)

[norwegen60]

Hallo,

ich habe in AdoQuery1 über
Select * from Tabel1 Daten aus Tabel1 abgefragt.

Jetzt möchte ich wissen, ob in Tabel1 neue Daten dazu gekommen sind und suche nach einer Möglichkeit, wie ich in AdoQuery2 nur die Daten abrufe, die in AdoQuery1 noch nicht enthalten sind. Die Möglichkeit, dass ich mir zum Zeitpunkt der Abfrage von AdoQuery1 MaxID oder Zeit merke scheidet aus, da die Tabelle über Replikation mit anderen Datenbanken verbunden ist und somit unterschiedliche ID-Bänder und Standort-Zeiten verwendet werden. Es müsste also etwas in der Art
Select * from Tabel1 where ID NOT IN (Select ID from AdoQuery1) sein.

Wie aber kann ich die Daten aus AdoQuery1 in die NOT IN-Abfrage einbinden?
Ich habe auch daran gedacht, die ID der ersten Abfrage in einem Array abzuspeichern, weiß aber auch nicht, wie dann NOT IN mit dem Array zusammenbringe

Danke
Gerd

[jaenicke]

Es geht um die Professional Edition aus deinem Profil? Hast du das FireDAC Addon?
Wenn ja, wäre FireDAC mit Local SQL Abfragen eine Möglichkeit. Damit kannst du Querys lokal in deiner Anwendung über nur im Speicher vorhandene Tabellen (TFDTable, TFDQuery, also wie deine AdoQuery1) durchführen. Im Grunde also genau was du willst.

Alternativ fiele mir nur ein die Daten mit select into zuerst in eine temporäre Tabelle zu kopieren und diese dann abzurufen. Dann könntest du die Vergleichsarbeit dem SQL Server überlassen und nur neue Datensätze hinzufügen. Dazu kannst du dann ein weiteres Feld hinzufügen, dass nach dem Abruf mit dem du die Daten jeweils als "abgerufen" markierst. So hast du dann nur eine Tabelle, die du neu abrufen musst und kannst über das Feld nachschauen was neue Daten sind und was nicht.

[Uwe Raabe]

Eine weitere Alternative wäre, das zweite Dataset mit den neuen Daten zu filtern (Filter := true) und im OnFilterRecord zu püfen, ob der Datensatz im ersten Dataset vorkommt. Das sollte dann auch für jede Zugriffskomponente und jede Datenbank funktionieren und erfordert am wenigsten Code.

[norwegen60]

Danke für die Tips.

Ich verwende die UniDac-Komponenten, bin aber nicht sicher, ob die die Daten lokal speichern können. Wie soll das denn gehen?
Mir ist aber nicht klar, wie dann eine Abfrage mit Bezug auf die zuvor geladene UniQuery1 lauten müsste.Select * from Tabel1 where ID NOT IN (Select ID from UniQuery1) geht ja nicht.
Ich weiß auch nicht, wie ich einen Filter festlege, der die Daten aus UniQuery1 ausschließt. Hier kommt noch das Problem dazu, dass dann UniQuery2 auch wieder alle Daten lädt, was ich eigentlich mit dem NOT IN vermeiden wollte.

Gerd

[DeddyH]

Wie wäre es mit einem kleinen Umweg (ungetestet)?

Delphi-Quellcode:

Liste := TStringList.Create;
try
  UniQuery1.SQL.Text := 'SELECT ID FROM Tabelle';
  UniQuery1.Open;
  Feld := UniQuery1.FieldByName('ID');
  while not UniQuery1.Eof do
    begin
      Liste.Add(Feld.AsString);
      UniQuery1.Next;
    end;
  UniQuery1.Close;
  if Liste.Count > 0 then
    begin
      UniQuery2.SQL.Text := Format('SELECT * FROM Tabelle WHERE ID NOT IN(%s)',[Liste.CommaText]);
      UniQuery2.Open;
    end;  
finally
  Liste.Free;
end;

[norwegen60]

Zitat von DeddyH:

Wie wäre es mit einem kleinen Umweg (ungetestet)?

Es hat geklappt damit die Werte in die NOT IN Abfrage zu bekommen. Die Laufzeit der Abfrage lag dann aber im Minutenbereich => nicht praktikabel
Ich hatte bewusst verschwiegen dass es sich um ca. 1 Mio Daten handelt (nur drei Felder). Ich hatte den Aufschrei vermeiden wollen.
Es ging und geht mir aber auch um die Technik selber.

Zitat von jaenicke:

Ob es so etwas bei UniDac auch gibt, weiß ich nicht. Es wäre allerdings enttäuschend und für uns ein NoGo, wenn nicht. Dazu müsste aber jemand anderes etwas sagen, der UniDac benutzt. Da gibt es ja im Forum einige, die das gegenüber FireDAC (was wir benutzen) in den Himmel loben. Wo seid ihr?

Wie würde die Abfrage in FireDac denn aussehen? Einfach UniQuery2.SQL.Text := 'Select * from Table where ID NOT IN (select ID from UniQuery1)' kann es ja nicht sein. Woher soll das SQL UniQuery1 kennen? Letztlich wird aber das Zeitverhalten ähnlich wie zuvor sein.

Zitat von mikhal:

Einen solchen Zeitstempel kann ich unabhängig von der Datenquelle (Stichwort Replikation) mit einem Trigger erzeugen und der Zieltabelle mitgeben.

Wie soll das gehen? Die Tabelle hat einen Zeitstempel. Da der aber vom Server abhängig ist kann es zu Zeitversätzen kommen.

Zitat von Uwe Raabe:

Ich weiß, ist keine wirkliche Hilfe in diesem Fall, aber in Interbase würde man das mit Change Views lösen. Die werden auch von FireDAC direkt unterstützt.

Da muss ich noch mal schauen ob es sowas bei UniDac gibt. Als ich es vor Jahren mal angefragt hatte, ging es nicht

Danke für die Feedbacks, auch wenn ich noch nicht die richtige Lösung habe.
Vielleicht bleib ich doch dabei, dass ich mir im zweiten Query alle Daten älter 24h lade und dann Satz für Satz vergleiche. Ich hatte gehofft es gibt einen besseren Weg.

[jaenicke]

Zitat von norwegen60:

Ich verwende die UniDac-Komponenten, bin aber nicht sicher, ob die die Daten lokal speichern können. Wie soll das denn gehen?

In FireDAC würde deine Abfrage gehen, ja. Sprich einfach auf dem Namen der Komponente als Tabelle.

Ob es so etwas bei UniDac auch gibt, weiß ich nicht. Es wäre allerdings enttäuschend und für uns ein NoGo, wenn nicht. Dazu müsste aber jemand anderes etwas sagen, der UniDac benutzt. Da gibt es ja im Forum einige, die das gegenüber FireDAC (was wir benutzen) in den Himmel loben. Wo seid ihr?

[mikhal]

Ich nutze UniDAC, habe aber ein solches Konstrukt noch nie benötigt. Um festzustellen, ob neue Datensätze in einer Tabelle hinzugekommen sind, setze ich entweder eine VirtualTable ein (speicherintensiv und bei großen Datenmengen nicht gerade performant), eine temporäre Tabelle (Zeitaufwand bei der Erzeugung) oder besser einen Zeitstempel ein (wenig Speicherbedarf und performant). Einen solchen Zeitstempel kann ich unabhängig von der Datenquelle (Stichwort Replikation) mit einem Trigger erzeugen und der Zieltabelle mitgeben.

Grüße
Mikhal

PS: Ich weiß auch nicht, ob es überhaupt geht.