Optimierung Datenbankzugriff Firebird

[Perlsau]

Zitat von jobo:

Ich kann Furtbichlers Maßnahmen nur unterstreichen.

Ich auch!

Zitat von jobo:

Verwendung z.B. ADO mit MAXRECORDS z.B. gleich 1000

Das gibt's beim IBDac-Query nicht.

Zitat von jobo:

Ableitung von TADOQuery/TADODataset wandelt Filter & Sort in Where-Bedingung/Order By um.

Das versuche ich gerade, erhalte aber eine Fehlermeldung beim Versuch, den Filter zu setzen. Natürlich hab ich das bereits viele Male gemacht, aber noch nie mit den IBDac-Queries. Die Fehlermeldung lautet: Feld nicht gefunden. Dabei wird als Name des angeblich nicht gefundenen Feldes das Filterkriterium gemeldet:

Column unknown
BRASILIEN

Die Procedure, die aufgerufen wird:

Delphi-Quellcode:

procedure TDatMod.SetFilter_OrteLand(Land: String);
begin
  View_Orte.FilterSQL := 'V_LAND=' + Land;
end;

// Example aus IbDac.pdf:
// Query1.FilterSQL := 'Dept >= 20 and DName LIKE ''M%''';

Wobei das Property FilterSQL laut Dokumentation nichts anderes macht als:
Used to change the WHERE clause of SELECT statement and reopen a query.

Übrigens derselbe Fehler, der auch beim Setzen der gewöhnlichen Filtereigenschaft auftritt, wie ich es zuerst versucht hatte:

Delphi-Quellcode:

procedure TDatMod.SetFilter_OrteLand(Land: String);
begin
  View_Orte.Filtered := False;
  View_Orte.Filter := 'V_LAND=' + Land;
  View_Orte.Filtered := True;
end;

Schon irgendwie seltsam ... vielleicht 'n Bug ...

[mkinzler]

View_Orte.FilterSQL := 'V_LAND=' + QuotedStr(Land);

[Lemmy]

nein, das ist korrekt:

Zitat von Perlsau:

Delphi-Quellcode:

procedure TDatMod.SetFilter_OrteLand(Land: String);
begin
  View_Orte.FilterSQL := 'V_LAND=' + [B]QuotedStr(Land)[/B];
end;

du musst den Suchert in ' einschließen - ist ja auch ein String den Du suchst...

Grüße

[Perlsau]

Zitat von Lemmy:

du musst den Suchert in ' einschließen - ist ja auch ein String den Du suchst...

Hi Lemmy,
manchmal sieht man den Baum vor lauter Wald nicht mehr. Das funktioniert natürlich

[Hansa]

Zitat:

Zitat von jobo:

Verwendung z.B. ADO mit MAXRECORDS z.B. gleich 1000

Das gibt's beim IBDac-Query nicht.

Das gibts wirklich nicht, aber es gibt z.B. :

Code:

SELECT FIRST 1000 FROM ...

Aber mich wundert etwas, dass TClientDataSet noch nicht vorgeschlagen wurde. Es geht doch darum, dass schon sehr viele Daten angezeigt und/oder sortiert werden sollen ? Was spricht da gegen ein ClientDataSet (CDS) ? Ohne jetzt eine Indexorgie auf Datenbankebene anzetteln zu müssen könnte man die Daten doch zunächst mal in ein CDS einlesen und dieses könnte man ja anzeigen (geht sogar mit DBgrid) oder es lässt sich einfach sortieren. Für Letzteres reicht ja schon lediglich die Angabe des zu sortierenden Feldes. Also z.B. so:

Code:

CdsDM.CDS.IndexFieldNames := 'NR';

Was spricht dagegen, das so zu machen ?

[Perlsau]

[QUOTE=Hansa;1214317]

Zitat:

Ohne jetzt eine Indexorgie auf Datenbankebene anzetteln zu müssen könnte man die Daten doch zunächst mal in ein CDS einlesen und dieses könnte man ja anzeigen (geht sogar mit DBgrid) oder es lässt sich einfach sortieren.

Ich hab's jetzt so gelöst: Oberhalb des Grids liegt nun ein Panel, das verschiedene Auswahl-Komponenten aufnimmt:

Eine TComboBox, die die sortierten Ländernamen enthält und an Position 0 den Eintrag _Alle. Stellt der Anwender die ComboBox auf _Alle, entzieht ihm die Anwendung die Möglichkeit, beim Start sortieren zu lassen.
Dafür liegt auf dem Panel noch eine TDBCheckBox, die mit bei Auswahl von 0 unchecked wird und gleichzeitig readonly. In der Doku bzw. Hilfe wird das dem Anwender dann genauer erklärt werden.
Ich bin jetzt gerade dabei, weitere Auswahl-Combos zur Einschränkung der Datenmenge zu implementieren.
Diese Lösung gefällt mir recht gut, weil sie mir sehr flexibel scheint und die Sortierzeit auf ein bis zwei Sekunden beschränkt, wobei ich bei weiteren Einschränkungen sicher noch unter eine Sekunde komme.

Ich glaube nicht, daß die Sortierzeit bei Verwendung eines CDS wesentlich kürzer wäre, denn die Arbeit, die der Prozessor dabei zu verrichten hat, ist im Grunde dieselbe.