Optimieren der Datenbankabfragen für Reportpipelines

[nahpets]

Hallo,

Zitat:

Zitat von erich.wanker

@nahpets

Hallo, vielen Dank für deine Hilfe.

Ich würd sehr ungern meine SQl-Querys gegen Table's austauschen.
Funktionieren tut das ganze ja - nur halt zu langsam ..

Ich denk, das grad die Query -SQLStatements (oder auch Table -Filter) die Hauptbremsen sind - weil si so oft vorkommen.

Die Tables würden mir ja die komplette Datenbank (alle Tabellen) auf den Client holen - (Performance vom Netz!) - vie SQL Statemnts hol ich mir wenigstens nur die "affected Rows" - nur halt zu oft ..

Erich

der Filter funktioniert auch mit Querys, die haben dann halt ein Select * from tabelle und der Filter sorgt bei Querys genauso für die Einschränkung, wie bei Tables, es ist letztlich eine Funktionalität von TDataset, die alle Abkommen davon erben. Du musst also nicht auf Deine Querys verzichten.

[hoika]

Hallo,

ob Table.Filter eine Query loslässt hängt von der Komponente ab.
ZEOS macht das aber glaube ich wirklich so.

Die haben doch einen SQL-Monitor, den würde ich mal anwerfen.

Viell. hilft ja auch ein Neubau der Indizes.
(alter index inactive / alter index active).

Aber zuerst muss mal rausgefunden werden,
was so lange dauert (viele Selects / Traffic / fehlende Indizes)

Da würden unter FB2 viell. auch die Monitoring Tabellen helfen.


Heiko

[Blup]

Wenn für die Anzeige nicht alle Daten der Tabelle benötigt werden, könnte man die urspüngliche Bedingung für den Master auch bei jeder Detailabfrage mit angeben und erst danach filtern.
Im Prinzip so:

SQL-Code:

select *
from   t_kunden
where  (bedingung)

select    d.*
from      t_kunden k
left join t_details d on (d.id_kunde = k.id)
where     (bedingung)

select    a.*
from      t_kunden  k
left join t_details d on (d.id_kunde = k.id)
left join t_arbeit1 a on (a.id_detail = d.id)
where     (bedingung)

Alternativ eine Abfrage die alle erforderlichen Daten holt, diese in Objekten speichern und jeweils in TppJITPipeline bereitstellen.

[erich.wanker]

..ich werd mal folgendes in meine Anwendung einbauen ..


Ich schicke für jede Tabelle NUR EIN SQL-Statement zum Server.
Somit hab ich auf der Clientseite alle Daten für den Report.
Clientseitig setz ich dann bei den verschiedenen AfterScroll-Ereignissen div. Bookmarks...
Wenn Bookmarks gesetzt werden - druckt der Reportbuilder nur die gebookmarkten Datensätze
Wenn keine Bookmarks gesetzt sind, switche ich die Query für die Reportpipeline auf eine leere (zQuery2)

Delphi-Quellcode:

procedure TForm1.SpeedButton5Click(Sender: TObject);
var i:integer;
begin
  ppDBPipeline1.DataSource:=DataSource1;
  zquery1.DisableControls;
  i:=0;

      ppDBPipeline1.ClearBookmarkList;
      zquery1.First;
          while not zquery1.Eof do
          begin

                if AnsiContainsText(zquery1.FieldByName('OBJECT_NAME').AsString,edit1.Text) then  // <- somit spar ich mir ein SQL Statement
                begin
                ppDBPipeline1.SetBookmark;
                i:=1;
                end;

          zquery1.Next;
          end;




       if i = 0 then
       begin
       ppDBPipeline1.DataSource:=DataSource2; // keine Bookmarks wurden gesetzt
       end;

       ppReport1.Print;

  zquery1.EnableControls;
  zquery1.First;
end;

.ob das ganze dann wirklich schneller wird - werd ich noch berichten ..

LiGrü

Erich

[erich.wanker]

:-) ..

ok .. kurzum: es geht min. 10 mal schneller.

Alle benötigten Daten holen .. auf die relevanten ein Bookmark setzen und drucken lassen..