Query kopieren und Zeilen löschen

[Kaarsten]

Bei einer Abfrage über mehrere Tabellen mit FULL OUTER JOIN kann es zu doppelten Spaltenwerten kommen. Diese Query füttert eine DBGrid und dort sollen diese Zeilen ausgefiltert werden.

Meine Idee: Ich lade mir eine tempQuery und bearbeite diese. Danach kopiere ich sie in die eigentliche Query.

Ist das so machbar? Falls ja, dann stellen sich für mich folgende Fragen.

Wie kann man eine Query am einfachsten kopieren?
Wie kann man eine Zeile aus der Query löschen, oder aus einer anderen Kopie zufügen?

Wie gesagt, die Queries sind vom Aufbau her identisch.

Scheinbar ist diese Vorgehensweise vollkommen ungewöhnlich, da ich beim googlen nichts darüber finden konnte.

[jobo]

Mmh, die Beschreibung klingt seltsam, kann mir vorstellen, dass es da bei google nichts zu holen gibt.
Zuallererst:
Wie wär es denn, die Query so zu schreiben, dass keine doppelten Spaltenwerte ausgeworfen werden.
Dann:
Eine Query enthält den Abfragetext (SQL) und beim Öffnen der Abfrage wird ein Dataset erzeugt (Ergebnis)
Was davon willst Du kopieren und bearbeiten?

Falls Du ernsthaft ein unpassendes Ergebnis zurechtfiltern willst. Mit SQL geht das sicher besser.

[Kaarsten]

Das Dataset möchte ich bearbeiten, oder komplett kopieren.

Geht das auch zeilenweise?

Mein Problem. Ich brauche fast alle Infos aus mehreren Tabellen. Verbunden werden die durch eine/zwei ID's. In den Tabellen kann diese ID allerdings potentiell mehrfach vorkommen. Daher bekomme ich potentiell mehrere Ergebnisse für diese ID. Das ist ja ok. Ein Group By mit Postgres ist echt aufwendig.

Daher ist diese Lösung eventuell ein Weg?

Das Ergebnis des SQL liefert mir z.B. 4 Ergebnisse für die gleiche ID. Diese werden dann in der DBGrid angezeigt. Ich möchte dort aber nur ein Ergebnis.

DISTINCT hilft nicht, da die Datensätze unterschiedlich sind.

[baumina]

Ich denke deine Lösungsansatz ist nicht ganz der richtige Weg. Versuche die SQL-Abfrage so zu gestalten, dass sie dir genau das liefert was du haben möchtest. Es gibt hier genügend SQL-Experten, die dir dabei gerne helfen.

[Jumpy]

Zitat:

Zitat von Kaarsten (Beitrag 1232963)

Das Ergebnis des SQL liefert mir z.B. 4 Ergebnisse für die gleiche ID. Diese werden dann in der DBGrid angezeigt. Ich möchte dort aber nur ein Ergebnis.

DISTINCT hilft nicht, da die Datensätze unterschiedlich sind.

Entweder sind die Datensätze für die gleiche ID unterschiedlich (also die anderen relevanten Felder) dann sollten sie doch auch angezeigt werden, oder aber sie sind doch gleich, d.h. du bekommst einen Datensatz zu einer ID mehrfach (ggf. aus verschiedenen Quellen). In dem Fall reicht es doch ein Select Distinct um dein bisheriges SQL zu packen ala:

Code:

Select Distinct * From (Deine bisheriges SQl)

Zu deiner Idee und warum niemand mMn darauf eingeht:
a) es ist glaub ich nicht klar worauf die hinauswillst
b) du solltest glaub ich bestimmte Datensätze aus deinem Ergebnis rausfiltern (die die du nicht brauchst) willst aber stattdessen den anderen Weg gehen und die Datensätze, die du brauchst aus dem Ergebnis raus in ein anderes Grid beispielsweise kopieren. Das ist doch viel zu aufwendig und kompliziert, weswegen jeder hier vorschlägt doch einfach direkt die Ergebnisdatenmenge einzuschränken. Und auch wenn das deiner Meinung nach vllt. nicht geht, ist es vllt. mit Hilfe des Forums doch möglich, wir bräuchten nur mehr Infos dazu. Denn generell, wenn du deiner Lösung folgen würdest müsstest du doch auch die "brauchbaren" Datensätze irgendwie identifizieren können. Und diese Kriterien kann man doch sicher auch schon vorher im SQL unterbringen.

[Furtbichler]

1. Lade die Daten per normalem TQuery (oder was auch immer Du dafür verwendest)
2. Nimm ein TClientDataset, falls Du es hast, oder ein TkbMemTable. Oder TdxMemData, wenn Du DevExpress hast. Das sind In-Memory Datasets.
3. Überführe nur die eindeutigen Datensätze. Zum schnellen Prüfen eignet sich eine Dictionary am besten.

Aber wie schon alle vor mir gesagt haben: Mach es mit SQL. Das ist ein klassisches Problem, das z.B. mit Subselects oder Aggregaten (statt der JOINS) einfach zu lösen ist.

Kann aber auch sein, das deine Query einfach 'falsch herum ist'. Das wäre dann aber ein LEFT/RIGHT JOIN, was Du offenbar nicht hast.

Zeig den SQL-Code und dein spezifisches Problem (also Beispieldaten) und dir kann geholfen werden.

[Kaarsten]

Was mich interessieren würde ist einfach:
Kann man den Inhalt einer Query auf eine andere übertragen?

Geht so etwas wie: ZQueryTemp:= ZQuery ??

[p80286]

Na klar

Delphi-Quellcode:

Query1.SQL.Text:=Query2.SQL.Text

ist aber wohl nicht was Du erreichen willst.

Wie wäre es wenn du mal eine Tabellenbeschreibung und eine Beschreibung des gewünschten Ergebnisses posten würdest?

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von Kaarsten (Beitrag 1235181)

Kann man den Inhalt einer Query auf eine andere übertragen?

So sollte das funktionieren:

Delphi-Quellcode:

Procedure AppendDataset(aSource, aDestination : TDataSet);
Var
  bookmark : TBookmark;

  Procedure _AppendRow();
  Var
    field,dest : TField;

  Begin
    aDestination.Append;
    For field in aSource.Fields do begin
      dest := aDestination.FindField(field.FieldName);
      if dest <> nil then
        dest.Value = field.Value;
    end;
    aDestination.Post;

  End;

Begin
 bookmark = aSource.GetBookmark;
 aSource.DisableControls;
 Try
   aSource.First;
   while not aSource.Eof do begin
     _AppendRow();
     aSource.Next;
   end;
 Finally
    aSource.GotoBookmark(bookmark);
    aSource.FreeBookmark(bookmark);
    aSource.EnableControls;
 End;
End;

(Getippt und nicht getestet)

DAs ist natürlich so nicht das schnellste, weil jedes Mal 'FindField' aufgerufen wird. Wenn man sich das in einer Dictionary merkt, wird das viel flotter. Zudem sollte man wissen, das bei einem TDataset, welches an eine Datenbank gebunden ist, die neuen Zeilen sofort persitiert werden.

[Jumpy]

Ich hab letztens mal eine FireDac Demo gesehen. Da sah das so aus, als könnte man damit das Ergebnis einer Query als Basisdatenmenge für eine weitere Query nutzen, das könnte vllt. dann sowas sein.

Wobei auch ich mich den Vorrednern anschließe, dass das sicher (mit dem richtigen SQL-Statement) auch einfacher geht.