Selektierte Datenätze in neue Abfrage

[TKanne]

Hallo zusammen,

ich habe hier nun schon lange mitgelesen und konnte auch schon etliche Probleme durch Durchstöbern des Forums lösen.
Nun komme ich aber irgendwie nicht weiter.

Folgendes Problem:

Ich habe eine Anwendung mit einem DBGrid, das per ADO mit einer MySQL-Datenbank verbunden ist (ob ADO / MySQL nun die ideale Kombination ist, ist ein anderes Thema).

Per Tastendruck kann der Anwender einen oder mehrere Datensätze selektieren:

Code:

procedure Tfrm1.dbgrid1KeyPress(Sender: TObject;
  var Key: Char);
begin
  case Ord(Key) of
    77, 109:
      begin
        dbgrid1.SelectedRows.CurrentRowSelected := not dbgrid1.SelectedRows.CurrentRowSelected;
        dbgrid1.DataSource.DataSet.Next;
      end;
    13:
      // etwas anderes ...
  end;
end;

Dann kann man sich per Funktion nur die selektierten anzeigen lassen.
Soweit, so gut. Das klappt auch alles.

Nun sollen aus den selektierten Datensätzen eine neue Datenbankabfrage in einem neuen DBGrid erzeugt werden, wobei hierbei zusätzlich noch eine weitere Tabelle hinzuge-JOIN-t werden.

Hat jemand irgend eine Idee, wie man das am elegantesten lösen kann?
Ich dreh mich momentan gedanklich irgendwie im Kreis...

Vielen Dank schon mal für eure Hilfe,

TKanne

[haentschman]

Hallo...

tja, da wird dir nix anderes übrig bleiben als dein SQL in der Schleife über die Datensätze zusammenzusetzen.
Quasi...
- mit dem ersten "Selected" das "where" + deine Bedingung eröffnen
- mit jedem weiteren "Selected" ein "and" + deine Bedingung
- mit Eof dann das "order by" etc. dranhängen.

[Jumpy]

Ich würde die PrimärSchlüssel der selektierten Datensätze in einen String packen mit Klammern drum. Nenn den jetzt mal "Auswahl".

Dann einer neuen / oder ruhig auch der alten Query das neue SQL-Statement zuweisen

Query1.SQL.Text:='Select * From Ursprungstabelle u'
Query1.SQL.Text:='Left Join bla b on blabla'
Query1.SQL.Text:='Left Join blub bl on blubblub'
.
.
.
Query1.SQL.Text:='where u.ID in ('+Auswahl+')'

[haentschman]

um die "Auswahl" zu erzeugen mußt du auch über die Datenmenge laufen. Da kannst du es gleich da zusammensetzen. Der nächste Vorteil wäre, daß du dabei auch mit Parametern arbeiten kannst...
Anhängen, Parameter setzen

[TKanne]

Hallo,

danke für die schnellen Antworten.

@haentschman:
So etwas ähnliches hatte ich mir auch schon überlegt: Where (ID = X) OR (ID = Y) OR ...

Bei vielen selektierten Datensätzen könnte die WHERE-Klausel jedoch ziemlich lang werden. Gibt es da irgendwo ein Limit?

Ich hatte gedacht, man kann das evtl. irgendwie eleganter lösen mit TBookmark oder so.

@Jumpy:
OK, das wird dann auf jeden Fall etwas Kürzer als die OR-Verknüpfung.
Auch hier allerdings die Frage: Darf 'Auswahl' eine beliebige Länge haben?

[Sir Rufo]

Am elegantesten geht es, wenn du eine temp. Tabelle anlegst und bei jedem Auswählen eines Datensatzes diesen in die temp. Tab einfügst bzw. auch wieder löschst (nur den PK)

Das ist für den User gefühlt die schnellste Art

[TKanne]

Hmm, das mit der Temp-Tabelle wäre evtl. auch eine Variante, allerdings in diesem Fall ungünstig, da ich nur zu Auswertungen auf eine 'fremde' Datenbank zugreife und dort nur Leserechte habe.

[jobo]

Ich würde mich allen anschließen.

Code:

where [] in (...)

ist sicher eine einfache und preiswerte Möglichkeit.

Code:

[temptable]

bietet sich vor allem wegen der Performance an. Das hängt aber auch stark mit den erreichbaren Ausführungsplänen und Mengengerüsten zusammen. Weiß nicht, was der mySQL Optimizer alles kann.
Es muss nicht mal unbedingt "temp" sein. Eine permanente, userspezifische Tabelle könnte nicht nur die gewünschten Subselects liefern, sondern bspw. die letzten 10 Selektionen speichern....

P.S.: nur Leserechte passen natürlich eher zur ersten Variante

[TKanne]

Hallo,

danke für Eure Vorschläge.

So, ich habe es jetzt mit der

Code:

where [] in (...)

Variante gemacht.

Funktioniert erst einmal soweit, zumindest mit 1342 selektierten Datensätzen, und die Select-Zeit ist auch akzeptabel, zumindest wenn man temporär das Dataset auf DisableControls setzt.
Allerdings bin ich mir noch etwas unsicher, das es ab einer gewissen Anzahl evtl. zu Problemen kommen kann.

Das war ja im Prinzip auch mein Ansatz, hatte nur gedacht, das wäre etwas laienhaft und es gäbe eine elegantere Lösung.

Aber die Temp-Tabellen-Version bzw. das speichern der Selektion in einer speziellen Tabelle werde ich mir mal für ein anderes Projekt merken.

Also Vielen Dank erst einmal,
TKanne

[jobo]

Zu "where.. in.." sollte es je nach DB Version Limits geben (Doku, ..).
Welcher normale Benutzer selektiert aber per Klick mehr als 1000 Sätze?
Hier würde ich notfalls in der Anwendung ein Limit setzen oder auch in der Benutzerunterstützung. "select all" dürfte es dann nicht geben.