Tabelle/Query, die ihre Daten aus einer anderen Query bezieht

[RSE]

Hallo Leute,

wir arbeiten mit Delphi 5 und den IBObjects (TIBOQuery usw.). Gibt es die Möglichkeit, eine Query, ein Table oder irgendein anderes TDataSet so zu benutzen, dass es sich die Daten nicht aus der Datenbank, sondern aus einer anderen Query holt? Das Anwendungsszenario sieht folgendermaßen aus: Ich habe eine Tabelle, in der gesucht werden kann. Die Daten werden währenddessen in einem Tabellen-Control angezeigt. Nun möchte ich, dass sich bei jedem Tastenanschlag in einem Suchfeld die Anzeige weiter einschränkt. Ich kann also nicht jedes Mal eine neue DB-Anfrage machen, nur um eine Teilmenge der schon geholten Daten nochmals zu holen. Stattdessen möchte ich einfach die schon bekannten Daten nutzen und davon nur eine Teilmenge darstellen. Es handelt sich um größere Datenmengen (mehrere 10.000 Datensätze).

Ich weiß, dass das TClientDataSet dazu wie geschaffen ist. Dessen Einsatz steht aber außer Frage, da wir noch in Delphi 5 programmieren und hier die Nutzung nur erfolgen kann, wenn die midas.dll auf allen Clients installiert und registriert ist (Uses LibMidas ist erst ab D6 möglich) und das können wir nicht sicherstellen.

[jaevencooler]

Moin, Moin,


Die Idee eine Query mit dem kompletten Datenbestand einmalig öffnen, und dann mit einer weiteren Query
darauf zu greifen wird nicht funktionieren !

Schon mal über die Verwendung eines Filters nachgedacht, oder eventuell mit Locate arbeiten ?

Die bessere Alternative für eine schnelle Suche innerhalb der Daten ist auf jeden Fall die
Daten gut und geschickt zu indizieren, und alle Möglichkeiten Deines Datenbankservers zu nutzen.

Was für eine RDBMS setzt Du denn ein ?
(Ups, wer lesen kann ....)


Beste Grüße
Michael

[RSE]

Wenn ich bei jedem Tastenanschlag eine DB-Abfrage starten würde, dann wäre das einfach nur elendig langsam. Allein die Latenz durch das LAN ist doch schon zu langsam dafür - egal wie schnell der Server reagieren würde. Deshalb möchte ich die Einschränkung lokal berechnen, und zwar vorzugsweise nur für so viele Datensätze wie ich grad brauche (wie angezeigt werden).

Tastenanschlag -> Grid unter Berücksichtigung der neuen Bedingungen mit so vielen Datensätzen füllen, wie angezeigt werden

Das Ganze muss also in Sekundenbruchteilen (Hundertstel) passieren!

[Bummi]

klingt so als ob Du Filter verwenden solltest ....

[stahli]

Ich denke, der Ansatz ist nicht optimal. Ein Tastenanschlag (bzw. Suchänderung) könnte ja auch bedeuten, dass aus dem Suchstring etwas gelöscht wurde. Dann kommst Du mit einer weiteren Subfilterung nicht mehr zurecht.
Du solltest versuchen, immer komplett neu zu selectieren/zu filtern und diesen Vorgang bestmöglich zu optimieren. Das wäre jedenfalls mein Ansatz.

Ich habe ein altes Projekt, bei dem ich anhand von Sucheingaben einen Datensatz lokalisiere. Das erfolgt bei jeder Suchtextänderung indem erst in einer Straßen-Tabelle nach einem passenden Straßenindex gesucht wird und dann in einer Grundstücks-Tabelle nach dem Straßenindex und der passenden Hausnummer. Durch die Trennung in zwei Tabellen und Index-Verwendung geht das sehr schnell.

Vielleicht kannst Du ja Deine DB noch optimieren?

[dataspider]

Zitat:

Zitat von Bummi (Beitrag 1138591)

klingt so als ob Du Filter verwenden solltest ....

IBO setzt Filter in ein Where um und schickt die Abfrage zuzm Server.
Dieses lokale Filtern geht wohl z.B. in FibPlus.

Zitat:

Zitat von RSE (Beitrag 1138589)

Tastenanschlag -> Grid unter Berücksichtigung der neuen Bedingungen mit so vielen Datensätzen füllen, wie angezeigt werden

Das Ganze muss also in Sekundenbruchteilen (Hundertstel) passieren!

Wenn du das schaffst, geb ich einen aus.
Ich weiß ja nicht, was du als "Tabellencontrol" benutzt.
Aber allein das Neu Laden der gefilterten Daten in der Grid dauert lange genug.

Aus gutem Grunde gibt es dieses Verhalten in diversen LookUp - Komponenten.
Aber ich würde nie auf die Idee kommen, eine Rechnung über ein LookUp zu suchen.
Für Anreden, Mengenneinheiten - eben kleinere Tabellen - ist das OK.

Aber wenn du es versuchen willst, dann benutze diverse MemDatasets.
Diese können meist per Assign Daten und Struktur eines TDataSet übernehmen.

Ich würde aber bei so vielen Daten immer Eingabe - Enter - Suchen bevorzugen.
Evtll. noch durch einen Timer, welcher nach ca. 1 Sekunde Pause automatisch filtert.

Frank

[RSE]

Ich habe mich jetzt ein wenig zu TIBOQuery und Filtern belesen. In den IBO-FAQ steht folgendes:

Zitat:

The Locate() method for TIB_Query seems to work well. Is there a way to do a "LocateNext"?
You will find that this works rather nicely: instead of using the Locate() method, you can leave the Filtered property False and set a filter based on the value you are locating. Then, use the FindFirst, FindNext, FindLast, etc. methods to navigate through the records isolated by the locate (filter) criteria.

Ich denke ich werde dieses Verhalten benutzen. Ich fange dann bei jedem Tastenanschlag an zu filtern. Dabei werde ich Application.Processmessages einbauen und wenn zwischenzeitlich ein neuer Tastenanschlag aufgetreten ist, breche ich ab. Dann läuft die neu getriggerte Filterung an. So sollte das Ganze performant bleiben und trotzdem sofort Ergebnisse ausspucken.

[EarlyBird]

hat die Komponente eventuell ein onFilterRecord Ereignis?
In dem Ereignis kannst Du nach Deinen Kriterien Filtern.
Ich nutze es mit TMSQuery da funktioniert es super und blitz schnell

[joachimd]

Zitat:

Zitat von RSE (Beitrag 1138589)

Wenn ich bei jedem Tastenanschlag eine DB-Abfrage starten würde, dann wäre das einfach nur elendig langsam.

Ich mache dies i.d.R. so:

1. Ein Tastenanschlag zieht einen timer auf, der zB auf 100 ms eingestellt ist
   
   Delphi-Quellcode:

   timer1.enabled:=false; 
   timer1.interval:=100;
   timer1.enabled:=true;

2. im Timer-Event wird der Timer Disabled und die Daten geladen
   
   Delphi-Quellcode:

   timer1.enabled:=false; 
   //Lade Daten

3. Falls Du noch eine Einschränkung brauchst, weil zB Deine Komponenten immer komplett laden wollen, setze ein TOP 30 in das Statement
   
   SQL-Code:

   SELECT TOP 30 * FROM mytable WHERE <Filter-Bedingung>

[RSE]

Zitat:

Zitat von joachimd (Beitrag 1138626)

Falls Du noch eine Einschränkung brauchst, weil zB Deine Komponenten immer komplett laden wollen, setze ein TOP 30 in das Statement

SQL-Code:

SELECT TOP 30 * FROM mytable WHERE <Filter-Bedingung>

Ich glaube nicht, dass InterBase 6.1 das kann ;-) Zumindest unserer nicht.