Diese Lösung hat natürlich so sein Geschmäcke, da man hier ein Statement zusammenbaut. Änderungen an der Datenbank ziehen plötzlich an zig verschiedenen Stellen (einmal eingeführt wird das an zig Stellen so benutzt) Änderungen mit sich.
Also Records anhand der ID zu lesen ist so mit das unveränderlichste, was ich kenne. "Geschmäckle" hat es
imho nur, wenn man den Automatismus ansetzt:"Huch, eine
Query wird gebaut! Gefahr!
SQL-Injection! Iiiehh!". Dagegen ist zunächst nichts einzuwenden. Zunächst, denn...
... nun ist das aber mindestens in ORM gang und gäbe, und eine IN-Selektion über Integer-Werte über eine selbstgebaute Funktion zu erstellen ist doch gefahrlos möglich. Das geht in jedem Fall schneller, als sich von hinten durch die Brust ins Auge eine extrem unperformante Lösung auszudenken.
Leider wurde beim 'IN' Operator die Parametrierungsmöglichkeit vergessen. Also macht man da eine Ausnahme: Man wird weder geteert noch gefedert und ausgelacht aus nicht.
Zitat:
Eine statische Abfrage nach den Werten SELECT f1, f2, f3 FROM foo WHERE id=:id
Wo ist bei dieser Abfrage der konzeptionelle Unterschied zu einer IN-Abfrage? Ach, der Datentype? Und wenn der Name 'id' verändert wird?
Selektierte Datensätze in ein ClientDataset, die Daten (
XML oder Binär) mit der Information was das denn bitteschön ist an den Reporter mit dem/den gewünschten Report/s.
Wieso kein TDataset? Verstehe ich nicht. Da mach ich doch wieder Klimmzüge.
Dataset mit Parametrierung des Reports (und dieses eine Mal ein SELECT mit IN zusammengebaut). Fertig. Das ganze an den Report geflanscht und schon kann es losgehen. Das mit dem "
XML oder Binär" habe ich nicht verstanden.
@mjustin: Das stimmt, da kommt es auf das RDBMS an. ich glaube, beim
SQL-Server gibt es kein Limit. Aber wenn der Benutzer 100000 IDs ausgewählt hat, hat er selbst Schuld... Ich weiß, ein kleiner Button 'SELECT ALL' und -wupps- hat man den Salat.