Bericht langsam

[Sven Seynsche]

Hallo zusammen,

sitze mal wieder vor einem (wahrscheinlich kleinem) Problem (mit
AC03-WinXP)
Habe eine Query, die rund 2500 Datensätze ergibt. Das geht auch ganz
schnell.
Wenn ich jetzt einen Bericht mit dem o.a. Query als Recordset mache,
und auf die letzte Seite gehe, dauert es ewig.
Dabei habe ich nur eine Gruppierung (Datum-Jahr), und jeweils über ein
Jahr Anzahl und Summe. Also eigentlich nix besonderes, denke ich.

Jetzt habe ich mal testweise eine Bericht ohne alle
Grupierungen/Summen gemacht, aber es dauert immer noch ewig.

Ist das normal, oder habe ich irgendwo eine Performance-Bremse drin?

Falls das Normal wäre, muss ich den Bereicht doch noch per Formular
vorher einschränken.

Vielen Dank für einen Tipp.
Sven

PS: Habe natürlich versucht zu Googeln und Faqen, aber wahrscheinlich
habe ich da wieder die falschen Suchbegriffe verwandt.... :-)

[Jörg Ackermann]

Hi,

Post by Sven Seynsche
sitze mal wieder vor einem (wahrscheinlich kleinem) Problem (mit
AC03-WinXP)
Habe eine Query, die rund 2500 Datensätze ergibt. Das geht auch ganz
schnell.
Wenn ich jetzt einen Bericht mit dem o.a. Query als Recordset mache,
und auf die letzte Seite gehe, dauert es ewig.
Dabei habe ich nur eine Gruppierung (Datum-Jahr), und jeweils über ein
Jahr Anzahl und Summe. Also eigentlich nix besonderes, denke ich.
Jetzt habe ich mal testweise eine Bericht ohne alle
Grupierungen/Summen gemacht, aber es dauert immer noch ewig.
Ist das normal, oder habe ich irgendwo eine Performance-Bremse drin?

Ohne Deine Abfragen, Inizes usw. zu kennen...
ja, das ist schon normal.
Access muß ja, um zB. Seitenzahlen zu berechnen
*alle* Seiten rendern.
Das dauert halt etwas länger...

Post by Sven Seynsche
Falls das Normal wäre, muss ich den Bereicht doch noch per Formular
vorher einschränken.

Prima Idee!

Gruß

[Sven Seynsche]

Hallo

On Tue, 13 Dec 2005 15:33:15 +0100, Jörg Ackermann

Post by Jörg Ackermann

Post by Sven Seynsche
Habe eine Query, die rund 2500 Datensätze ergibt. Das geht auch ganz
schnell.
Wenn ich jetzt einen Bericht mit dem o.a. Query als Recordset mache,
und auf die letzte Seite gehe, dauert es ewig.

Ohne Deine Abfragen, Inizes usw. zu kennen...
ja, das ist schon normal.

Dachte, wenn die Query entsprechend schnell ist, dass dann die
Performance nicht mehr daran hängen dürfte. Mal wieder was dazu
gelernt. Wobei ich ja "nur" über ein Datum-Feld aus dem Query
gruppiere und summiere. Und da ist in der Tabelle ein Index drauf....

Post by Jörg Ackermann
Access muß ja, um zB. Seitenzahlen zu berechnen
*alle* Seiten rendern.
Das dauert halt etwas länger...

Aha, gut, ja die erste Seite ist auch schnell da, aber wehe ich drücke
dann "letzte Seite". Für 82 Seiten braucht AC dann über 50 sec.

Post by Jörg Ackermann

Post by Sven Seynsche
Falls das Normal wäre, muss ich den Bereicht doch noch per Formular
vorher einschränken.

Prima Idee!

Ne, gefällt mir eigentlich nicht ;-)
Aber wenn es nett anders geht...

Danke und viele Grüße
Sven

[Henry Habermacher [MVP Access]]

Hallo Sven

Post by Sven Seynsche
Aha, gut, ja die erste Seite ist auch schnell da, aber wehe ich drücke
dann "letzte Seite". Für 82 Seiten braucht AC dann über 50 sec.

Das heisst knapp eine halbe Sekunde pro Seite, bei 30 Datensätzen pro Seite
sind das gerade mal 20 Milisekunden je Datensatz, was ja nicht gerade
langsam ist.

Dennoch: Hast Du evt. Domain Aggregat Funktionen bei den Formularfeldern
drin? Oder zeigst Du die Felder unverändert an? Verwendest Du viele Format
Funktionen? Oder vielleicht DropDowns im Report? Falls ja, dann solltest Du
die Recordsource des Bereichts dahingehend ändern, dass Du dies nicht im
Report selber machen musst, sondern die Recordsource bereits mit den
richtigen Feldern daherkommt. Wenn Du nach dem Jahr im Datum drin gruppieren
willst, dann solltest Du bereits in der Query das Jahr als separates Feld
zusätzlich führen, also z.B:

SELECT DeinDatum, Year(DeinDatum) As DeinJahr, ...

und dann den Bereicht nach DeinJahr gruppieren, das geht vermutlich
schneller. Die Summenbildung solltest Du aber im Bericht drin lassen können.
Das sollte Access auch einigermassen schnell hinbekommen.

Du musst daran denken, dass um auf die 80-ste Seite zu gehen, Access restlos
alle Datenfelder der vorhergehenden Seiten formatieren muss, damit es weiss,
wo es Seitenunbrüche machen muss. Es kann dies erst ermitteln, wenn es die
einzelnen Detailsätze komplett durchformatiert hat, erst dann ist die Grösse
des Detailbereichs bekannt und erst dann weiss Access, ob es jetzt diesen
Detailsatz noch auf die gleiche Seite oder auf die nächste Seite legen muss.
Falls dieser auf die nächste Seite muss, dann muss dieser nochmals
formatiert werden (deshalb gibt's beim Formatieren ja auch den FormatCount
Parameter)

Also kontrolliere mal, was genau Du im Report und bei den einzelnen
Datensätzen an Berechnungen/Formatierungen auslöst, dann kannst Du beginnen
zu optimieren.

Wenn Du genau wissen willst, was Access so im Hintergrund macht, dann
solltest Du mal den JetShowPlan aktivieren und dann schauen, was da alles
gemacht wird, wenn ein Report aufbereitet wird. Du wirst erstaunt sein, was
Access aus Deiner Query macht, um diese für den Report in eine passende
Abfrage umzuwandeln. Wie man den JetShowPlan aktiviert und auswertet, ist in
einem WhitePaper beschrieben, das es beim www.dbdev.org im Download Bereich
gibt.

Gruss
Henry

[Sven Seynsche]

Hallo Henry,

Post by Henry Habermacher [MVP Access]
Dennoch: Hast Du evt. Domain Aggregat Funktionen bei den Formularfeldern
drin? Oder zeigst Du die Felder unverändert an? Verwendest Du viele Format
Funktionen? Oder vielleicht DropDowns im Report? Falls ja, dann solltest Du
die Recordsource des Bereichts dahingehend ändern, dass Du dies nicht im
Report selber machen musst, sondern die Recordsource bereits mit den
richtigen Feldern daherkommt. Wenn Du nach dem Jahr im Datum drin gruppieren
willst, dann solltest Du bereits in der Query das Jahr als separates Feld

Ne, Domain Aggregat keine, Formatierung "nur" pro Jahr jeweils eine.
Es geht um aufadierte Zeiten. Die einzelnen Zeiten lassen ich im Query
in hh.mm umwandeln, und pro Datensatz gibt es noch die Minuten, die
pro Jahr addiert (und dann umformatiert werden).
Sind aber auch nur 15-20 Formatierungen.

Post by Henry Habermacher [MVP Access]
SELECT DeinDatum, Year(DeinDatum) As DeinJahr, ...
und dann den Bereicht nach DeinJahr gruppieren, das geht vermutlich
schneller. Die Summenbildung solltest Du aber im Bericht drin lassen können.
Das sollte Access auch einigermassen schnell hinbekommen.

Das mit dem Jahr habe ich mal geamcht, bringt immerhin eine Halbierung
der Zeit.

Post by Henry Habermacher [MVP Access]
Du musst daran denken, dass um auf die 80-ste Seite zu gehen, Access restlos
alle Datenfelder der vorhergehenden Seiten formatieren muss, damit es weiss,
wo es Seitenunbrüche machen muss. Es kann dies erst ermitteln, wenn es die
einzelnen Detailsätze komplett durchformatiert hat, erst dann ist die Grösse
des Detailbereichs bekannt und erst dann weiss Access, ob es jetzt diesen
Detailsatz noch auf die gleiche Seite oder auf die nächste Seite legen muss.
Falls dieser auf die nächste Seite muss, dann muss dieser nochmals
formatiert werden (deshalb gibt's beim Formatieren ja auch den FormatCount
Parameter)
Also kontrolliere mal, was genau Du im Report und bei den einzelnen
Datensätzen an Berechnungen/Formatierungen auslöst, dann kannst Du beginnen
zu optimieren.

Das war/ist ja mein Problem. Ich habe schon so ziemlich alles
rausgeworfen, was da war. Deswegen die Frage in die NG. Seit Monaten
steht das Optimieren des Berichts auf meiner To-Do-Liste mit ca. gar
keinem Erfolg (bis jetzt).

Post by Henry Habermacher [MVP Access]
Wenn Du genau wissen willst, was Access so im Hintergrund macht, dann
solltest Du mal den JetShowPlan aktivieren und dann schauen, was da alles
gemacht wird, wenn ein Report aufbereitet wird. Du wirst erstaunt sein, was
Access aus Deiner Query macht, um diese für den Report in eine passende
Abfrage umzuwandeln. Wie man den JetShowPlan aktiviert und auswertet, ist in
einem WhitePaper beschrieben, das es beim www.dbdev.org im Download Bereich
gibt.

Ja, stimmt. Da hätte ich auch schon mal drauf kommen können.
Jetshowplan habe ich nämlich schon mal aktiviert.
Werde gleich mal einen Blick drauf werfen.

Post by Henry Habermacher [MVP Access]
Gruss
Henry

Vielen Dank und viele Grüße zurück
Sven

[Karl Donaubauer]

Post by Sven Seynsche

Post by Jörg Ackermann

Post by Sven Seynsche
Habe eine Query, die rund 2500 Datensätze ergibt. Das geht auch ganz
schnell.
Wenn ich jetzt einen Bericht mit dem o.a. Query als Recordset mache,
und auf die letzte Seite gehe, dauert es ewig.

Ohne Deine Abfragen, Inizes usw. zu kennen...
ja, das ist schon normal.

Dachte, wenn die Query entsprechend schnell ist, dass dann die
Performance nicht mehr daran hängen dürfte. Mal wieder was dazu
gelernt. Wobei ich ja "nur" über ein Datum-Feld aus dem Query
gruppiere und summiere. Und da ist in der Tabelle ein Index drauf....

Post by Jörg Ackermann
Access muß ja, um zB. Seitenzahlen zu berechnen
*alle* Seiten rendern.
Das dauert halt etwas länger...

Aha, gut, ja die erste Seite ist auch schnell da, aber wehe ich drücke
dann "letzte Seite". Für 82 Seiten braucht AC dann über 50 sec.
...

82 Seiten sind relativ viel.

Du schreibst, die Abfrage sei "schnell". Bist du im Abfrageergebnis
eh zum letzten DS gehüpft? Oft wird die erste Anzeige-Seite schnell
geliefert und der Rest dann langsam und schrittweise hinten nach.

Du kannst auch testweise die Abfrage in eine Tabellenerstellungsabfrage
umwanden und den Bericht auf dieser neuen Tabelle basieren lassen.
Bringt's was oder ist der Bericht genauso langsam?

[Sven Seynsche]

Hallo Karl,

Post by Karl Donaubauer
82 Seiten sind relativ viel.
Du schreibst, die Abfrage sei "schnell". Bist du im Abfrageergebnis
eh zum letzten DS gehüpft? Oft wird die erste Anzeige-Seite schnell
geliefert und der Rest dann langsam und schrittweise hinten nach.

Ja, auch der letzte DS ist (fast) sofort da.

Post by Karl Donaubauer
Du kannst auch testweise die Abfrage in eine Tabellenerstellungsabfrage
umwanden und den Bericht auf dieser neuen Tabelle basieren lassen.
Bringt's was oder ist der Bericht genauso langsam?

Bringt einiges. Wau. Also liegt es doch an der Query. Das Erstellen
der Tabelle dauert ca. 15 sec, der Report ist dann auch quasi sofort
(<1sec) da.
Dabei ist er jetzt sogar um 11 Seiten länger ;-))

Also wäre es jetzt programmatisch richtig, per Code erst die Tabelle
erstellen zu lassen, und dann den Report zu erstellen?
Oder war das der erste Schritt zur Findung der Performance-Bremse?

Schon Mal vielen Dank für den Tipp und viele Grüße
Sven

[Karl Donaubauer]

Post by Sven Seynsche

Post by Karl Donaubauer
82 Seiten sind relativ viel.
Du schreibst, die Abfrage sei "schnell". Bist du im Abfrageergebnis
eh zum letzten DS gehüpft? Oft wird die erste Anzeige-Seite schnell
geliefert und der Rest dann langsam und schrittweise hinten nach.

Ja, auch der letzte DS ist (fast) sofort da.

Post by Karl Donaubauer
Du kannst auch testweise die Abfrage in eine
Tabellenerstellungsabfrage umwanden und den Bericht auf dieser neuen
Tabelle basieren lassen. Bringt's was oder ist der Bericht genauso
langsam?

Bringt einiges. Wau. Also liegt es doch an der Query. Das Erstellen
der Tabelle dauert ca. 15 sec, der Report ist dann auch quasi sofort
(<1sec) da.
Dabei ist er jetzt sogar um 11 Seiten länger ;-))
Also wäre es jetzt programmatisch richtig, per Code erst die Tabelle
erstellen zu lassen, und dann den Report zu erstellen?
Oder war das der erste Schritt zur Findung der Performance-Bremse?
...

Beides ist möglich.
Man darf bei einem Bericht nicht nur die reine Zeit zum Aufbau
der Datenherkunft rechnen. Berichte werkeln im Hintergrund
mit ihren eigenen Recordsets zum Aufbereiten der Daten.

Ich würde als erstes versuchen, die Abfrage zu optimieren.
Das ist ein weites Feld. Vielleicht sieht man schon etwas,
wenn du das SQL-Statement der Abfrage postest und
angibst, welche Felder in den beteiligten Tabellen indiziert sind.

Es kann aber auch durchaus sein, dass die reine Nutztabelle
die beste Optimierungsmöglichkeit ist. Das kommt (nicht nur)
bei Berichten öfter vor.

[Sven Seynsche]

Hallo Karl,

Post by Karl Donaubauer
Ich würde als erstes versuchen, die Abfrage zu optimieren.
Das ist ein weites Feld. Vielleicht sieht man schon etwas,
wenn du das SQL-Statement der Abfrage postest und
angibst, welche Felder in den beteiligten Tabellen indiziert sind.

SELECT Main.ATD, tblAC.ACREG, Main.FNO, Dep.ICAO, Dest.ICAO, Main.ATA,
T_M2h(DateDiff("n",[ATD],[ATA]),1) AS BLH, Main.APP, tblPos.Posextend,
tblSPC.SPC, Main.FDZ, Coc1.C_Name, Main.C2_Pos, Coc2.C_Name, Main.CAB,
Main.RMK,
SunCalcChk([main].[Dep_ID],[main].[Dest_ID],[main].[ATD],[main].[ATA])
AS NGT, DateDiff("n",[ATD],[ATA]) AS BLM
FROM (((tblSPC RIGHT JOIN (tblPos INNER JOIN (Cockpit AS Coc2 RIGHT
JOIN (Cockpit AS Coc1 RIGHT JOIN Main ON Coc1.C_ID = Main.C_ID) ON
Coc2.C_ID = Main.C2_ID) ON tblPos.ID = Main.Pos_ID) ON tblSPC.ID =
Main.SPC_ID) LEFT JOIN tblAF AS Dep ON Main.Dep_ID = Dep.AP_ID) LEFT
JOIN tblAF AS Dest ON Main.Dest_ID = Dest.AP_ID) INNER JOIN tblAC ON
Main.AC_ID = tblAC.AC_ID
ORDER BY Main.ATD;

Indizes sind auf
tblMain: ATD
tblAC, tblAF, tblCOC, tblPOS, tblSPC: die jeweilige ID (AC_ID, C_ID,
ID, usw.)

SunCalcChk berechnet Sonnenauf/untergang und gibt einen String zurück
T_M2h erzeugt einfach eine "schöne" Uhrzeit (hhh:mm) aus Minuten.

Post by Karl Donaubauer
Es kann aber auch durchaus sein, dass die reine Nutztabelle
die beste Optimierungsmöglichkeit ist. Das kommt (nicht nur)
bei Berichten öfter vor.

Okay. Schaun wir mal.
VlG
Sven

[Karl Donaubauer]

Post by Sven Seynsche

Post by Karl Donaubauer
Ich würde als erstes versuchen, die Abfrage zu optimieren.
Das ist ein weites Feld. Vielleicht sieht man schon etwas,
wenn du das SQL-Statement der Abfrage postest und
angibst, welche Felder in den beteiligten Tabellen indiziert sind.

SELECT Main.ATD, tblAC.ACREG, Main.FNO, Dep.ICAO, Dest.ICAO, Main.ATA,
T_M2h(DateDiff("n",[ATD],[ATA]),1) AS BLH, Main.APP, tblPos.Posextend,
tblSPC.SPC, Main.FDZ, Coc1.C_Name, Main.C2_Pos, Coc2.C_Name, Main.CAB,
Main.RMK,
SunCalcChk([main].[Dep_ID],[main].[Dest_ID],[main].[ATD],[main].[ATA])
AS NGT, DateDiff("n",[ATD],[ATA]) AS BLM
FROM (((tblSPC RIGHT JOIN (tblPos INNER JOIN (Cockpit AS Coc2 RIGHT
JOIN (Cockpit AS Coc1 RIGHT JOIN Main ON Coc1.C_ID = Main.C_ID) ON
Coc2.C_ID = Main.C2_ID) ON tblPos.ID = Main.Pos_ID) ON tblSPC.ID =
Main.SPC_ID) LEFT JOIN tblAF AS Dep ON Main.Dep_ID = Dep.AP_ID) LEFT
JOIN tblAF AS Dest ON Main.Dest_ID = Dest.AP_ID) INNER JOIN tblAC ON
Main.AC_ID = tblAC.AC_ID
ORDER BY Main.ATD;
Indizes sind auf
tblMain: ATD
tblAC, tblAF, tblCOC, tblPOS, tblSPC: die jeweilige ID (AC_ID, C_ID,
ID, usw.)
SunCalcChk berechnet Sonnenauf/untergang und gibt einen String zurück
T_M2h erzeugt einfach eine "schöne" Uhrzeit (hhh:mm) aus Minuten.
...

Ich gehe mal davon aus, dass du die Abfrage nur für den Bericht
brauchst, d.h. man dahingehend optimieren kann.

1. Wenn du eh im Bericht nochmal gruppierst/sortierst, dann schmeiß
die Sortierung aus der Abfrage raus, also kein ORDER BY.

2. Bei allem, was du an Berechnung in der Abfrage machst, kommt's
drauf an, ob du die Ergebniswerte im Bericht bereits vorneweg zum
Gruppieren oder Sortieren brauchst. Wenn nicht, dann teste, ob's was
bringt, die Berechnungen in den Bericht zu verlegen. Es kann durchaus
schneller sein, wenn du die eigenen und VBA-Funktionen wie T_M2h,
SunCalcChk, DateDiff, erst im Steuerelementinhalt des anzeigenden
Berichtssteuerelementes aufrufst.

[Sven Seynsche]

Hallo Karl,

On Wed, 14 Dec 2005 18:09:21 +0100, "Karl Donaubauer"

Post by Karl Donaubauer
Ich gehe mal davon aus, dass du die Abfrage nur für den Bericht
brauchst, d.h. man dahingehend optimieren kann.

Stimmt. Für andere Berichte/Formulare etc habe ich meist eine eigene
Abfrage.

Post by Karl Donaubauer
1. Wenn du eh im Bericht nochmal gruppierst/sortierst, dann schmeiß
die Sortierung aus der Abfrage raus, also kein ORDER BY.

Okay. Werde das ändern. War nur immer der Annahme, dass ich lieber
etwas in der Abfrage mache statt im Bericht. Aber da habe ich wohl
irgendwann mal was falsch verstanden.

Post by Karl Donaubauer
2. Bei allem, was du an Berechnung in der Abfrage machst, kommt's
drauf an, ob du die Ergebniswerte im Bericht bereits vorneweg zum
Gruppieren oder Sortieren brauchst. Wenn nicht, dann teste, ob's was
bringt, die Berechnungen in den Bericht zu verlegen. Es kann durchaus
schneller sein, wenn du die eigenen und VBA-Funktionen wie T_M2h,
SunCalcChk, DateDiff, erst im Steuerelementinhalt des anzeigenden
Berichtssteuerelementes aufrufst.

Werde ich auch heute mal probieren. Wie gesagt habe ich das immer
versucht anders herum zu machen, weil ich dachte die Abfrage macht das
schneller als der Bericht.
Und wenn das bei dem Bericht klappt, kann ich auch mal so alle anderen
Sachen durchprobieren (Argh) ;-)

Aber soweit erst Mal vielen Dank
Sven

[Henry Habermacher [MVP Access]]

Hallo Sven

Post by Sven Seynsche
SELECT Main.ATD, tblAC.ACREG, Main.FNO, Dep.ICAO, Dest.ICAO, Main.ATA,
T_M2h(DateDiff("n",[ATD],[ATA]),1) AS BLH, Main.APP, tblPos.Posextend,

Da wäre ja schon einer: DateDiff rechnet die differenz in Minuten zwischen
ATD und ATA aus. Das kannst Du auch direkt machen.

Beispiel:
? datediff("n", "1.1.2000", "31.12.2000")
525600
? (cdate("31.12.2000") - CDate("1.1.2000") ) * 24 * 60
525600

Da bei Dir ATD und ATA als Dates vorliegen, kannst Du also statt des
DateDiff Aufrufs direkt:

(ATA - ATD) * 1440 AS BLH

verwenden. Das geht wesentlich schneller, als die Funktion DateDiff 2500 mal
aufzurufen.

Des weiteren rufst Du T_M2h() mit DateDiff verschachtelt auf. Wieso
schreibst Du diese nicht um, so dass diese die Minutenermittlung gemäss
obigem Schema direkt aus ATD und ATA durchführt?

Post by Sven Seynsche
tblSPC.SPC, Main.FDZ, Coc1.C_Name, Main.C2_Pos, Coc2.C_Name, Main.CAB,
Main.RMK,
SunCalcChk([main].[Dep_ID],[main].[Dest_ID],[main].[ATD],[main].[ATA])

Hier gibt es sicher auch eine Optimierungsmöglichkeit. Was genau macht denn
SunCalcChk? Kannst Du das nicht direkt im SQL Statement drin machen?

Post by Sven Seynsche
AS NGT, DateDiff("n",[ATD],[ATA]) AS BLM

Auch hier gilt wieder das gleiche spiel mit der Minutenumwandlung

..

Post by Sven Seynsche
ORDER BY Main.ATD;

Der Order By in der Query kannst Du Dir schenken, den macht der Report
sowieso selber nochmals, ist nur Zeitverschwendung.

Post by Sven Seynsche
SunCalcChk berechnet Sonnenauf/untergang und gibt einen String zurück
T_M2h erzeugt einfach eine "schöne" Uhrzeit (hhh:mm) aus Minuten.

Und wieso nicht gleich im Report als Formatierung für das Feld, wenn es
ausgegeben wird? Wieso quälst Du da die Jet Engine mit Formatierungen, wenn
es um Performance geht? Lass das besser den Report machen, der muss sowieso
jedes Feld formatieren und da kannst Du ihm ja auch gleich angeben, wie er
es formatieren soll.

Nachdem Du nun bereits die halbe Zeit eingespart hast, hoffe ich, dass diese
Tipps nochmals die Zeit auf ca. 1/4 reduzieren werden, so dass Du dann statt
bei 80 Sekunden bei 5-8 Sekunden bist, wenn Du auf die letzte Seite
wechselst ;-)

Gruss
Henry

[Sven Seynsche]

Hallo Henry,

On Thu, 15 Dec 2005 16:40:03 +0700, "Henry Habermacher [MVP Access]"

Post by Henry Habermacher [MVP Access]
Da bei Dir ATD und ATA als Dates vorliegen, kannst Du also statt des
(ATA - ATD) * 1440 AS BLH
verwenden. Das geht wesentlich schneller, als die Funktion DateDiff 2500 mal
aufzurufen.
Des weiteren rufst Du T_M2h() mit DateDiff verschachtelt auf. Wieso
schreibst Du diese nicht um, so dass diese die Minutenermittlung gemäss
obigem Schema direkt aus ATD und ATA durchführt?

Danke für die Verbesserungen. Werde die heute oder morgen gleich mal
einbauen.
Da merke ich, dass ich zwar seit Jahren an meiner Datenbank rumbastel,
auch schon diverse Bücher gelesen habe, aber doch noch viele Basics
nicht oder nur unvollständig kenne. Gerade die Funktion Datediff habe
ich extrem oft gebraucht.
Werde also mal schauen, wo ich die noch einfach ersetzen kann.

Post by Henry Habermacher [MVP Access]
Hier gibt es sicher auch eine Optimierungsmöglichkeit. Was genau macht denn
SunCalcChk? Kannst Du das nicht direkt im SQL Statement drin machen?
Und wieso nicht gleich im Report als Formatierung für das Feld, wenn es
ausgegeben wird? Wieso quälst Du da die Jet Engine mit Formatierungen, wenn
es um Performance geht? Lass das besser den Report machen, der muss sowieso
jedes Feld formatieren und da kannst Du ihm ja auch gleich angeben, wie er
es formatieren soll.

SunCalcChk macht folgendes:
a) Es holt die geogr. Koordinaten der Orte Dep und Dest,
b) berechnet den Großkreis dazwischen (mit zwei weiteren
Schnittpunkten)
c) schaut dann, ob zum Zeitpunkt ActualTimeDeparture am Ort Dep, bei
ActualTimeArrival bei Ort Dest und an den Schnittpunkten es Nacht ist
d) und gibt dann das Ergebniss als String (T/O, Ldg, Crz, T_L, TCL)
zurück.
Wobei es dann eigentlich auch möglich sein müßte, den vom Bericht aus
aufzurufen.

Post by Henry Habermacher [MVP Access]
Nachdem Du nun bereits die halbe Zeit eingespart hast, hoffe ich, dass diese
Tipps nochmals die Zeit auf ca. 1/4 reduzieren werden, so dass Du dann statt
bei 80 Sekunden bei 5-8 Sekunden bist, wenn Du auf die letzte Seite
wechselst ;-)

Gibt es eigentlich ein Tool, dass solche Performance-Bremsen
(zumindest die offensichtlichen) findet? Die Acc-eigene Aalyse hat mir
da selbstredend nichts gezeigt.
Habe auch schon das Dokument zur AK7-Performance Tuning
durchgearbeitet. Aber das mit dem Datediff statt einfach subtrahieren
ist wohl doch zu banal ;-))
Auch dachte ich, es wäre eben beser solche Berechnungen im Query statt
im Bericht zu machen.
Aber Karl hat ja auch vorgeschlagen das mal anders zu machen. Dann
muss ja was dran sein :-))))

VG und vielen Dank
Sven

[Henry Habermacher [MVP Access]]

Hallo Sven

Post by Sven Seynsche
a) Es holt die geogr. Koordinaten der Orte Dep und Dest,
b) berechnet den Großkreis dazwischen (mit zwei weiteren
Schnittpunkten)
c) schaut dann, ob zum Zeitpunkt ActualTimeDeparture am Ort Dep, bei
ActualTimeArrival bei Ort Dest und an den Schnittpunkten es Nacht ist
d) und gibt dann das Ergebniss als String (T/O, Ldg, Crz, T_L, TCL)
zurück.
Wobei es dann eigentlich auch möglich sein müßte, den vom Bericht aus
aufzurufen.

Und da bist Du überrascht, dass das 20ms pro Datensatz dauert? Na ich weiss
nicht, das scheint mir nun doch ziemlich schnell zu sein. Du kannst das
allenfalls noch beschleunigen, wenn Du die geographischen Daten, die fix
bleiben, auch zur Tabelle ablegst, diese ändern sich ja für einen Ort nicht
und müssen nicht jedesmal neu errechnet werden, sind also sozusagen feste
Attribute (wenn auch genau genommen ein bisschen redundant).

Post by Sven Seynsche

Post by Henry Habermacher [MVP Access]
Nachdem Du nun bereits die halbe Zeit eingespart hast, hoffe ich,
dass diese Tipps nochmals die Zeit auf ca. 1/4 reduzieren werden, so
dass Du dann statt bei 80 Sekunden bei 5-8 Sekunden bist, wenn Du
auf die letzte Seite wechselst ;-)

Gibt es eigentlich ein Tool, dass solche Performance-Bremsen
(zumindest die offensichtlichen) findet? Die Acc-eigene Aalyse hat mir
da selbstredend nichts gezeigt.
Habe auch schon das Dokument zur AK7-Performance Tuning
durchgearbeitet. Aber das mit dem Datediff statt einfach subtrahieren
ist wohl doch zu banal ;-))
Auch dachte ich, es wäre eben beser solche Berechnungen im Query statt
im Bericht zu machen.

Nein, mir ist keines bekannt. Es gibt zwar WhitePapers (ich glaube mal bei
MS in der KB eines gesehen zu haben bezüglich Jet Performance), aber der
rest ist halt einfach Erfahrungssache und probieren, probieren, probieren
(und zwischen durch mal überlegen, was denn hinten dran so ablaufen könnte)

Gruss
Henry

[Sven Seynsche]

Hallo Henry

Post by Henry Habermacher [MVP Access]
Und da bist Du überrascht, dass das 20ms pro Datensatz dauert? Na ich weiss
nicht, das scheint mir nun doch ziemlich schnell zu sein. Du kannst das
allenfalls noch beschleunigen, wenn Du die geographischen Daten, die fix
bleiben, auch zur Tabelle ablegst, diese ändern sich ja für einen Ort nicht
und müssen nicht jedesmal neu errechnet werden, sind also sozusagen feste
Attribute (wenn auch genau genommen ein bisschen redundant).

Die Koordinaten habe ich in einer Tabelle, die bei der Abfrage
eingebunden ist. Habe das also geändert, so dass auch gleich die
Koordinaten vorliegen und nicht erst per lookup geholt werden müssen.

Post by Henry Habermacher [MVP Access]

Post by Sven Seynsche

Post by Henry Habermacher [MVP Access]
Nachdem Du nun bereits die halbe Zeit eingespart hast, hoffe ich,
dass diese Tipps nochmals die Zeit auf ca. 1/4 reduzieren werden, so
dass Du dann statt bei 80 Sekunden bei 5-8 Sekunden bist, wenn Du
auf die letzte Seite wechselst ;-)

Ja, stimmt genau: 5 Sekunden! Deine Kristallkugel ist wirklich gut
:;-)))

Post by Henry Habermacher [MVP Access]

Post by Sven Seynsche
Gibt es eigentlich ein Tool, dass solche Performance-Bremsen
(zumindest die offensichtlichen) findet? Die Acc-eigene Aalyse hat mir
da selbstredend nichts gezeigt.

Nein, mir ist keines bekannt. Es gibt zwar WhitePapers (ich glaube mal bei
MS in der KB eines gesehen zu haben bezüglich Jet Performance), aber der
rest ist halt einfach Erfahrungssache und probieren, probieren, probieren
(und zwischen durch mal überlegen, was denn hinten dran so ablaufen könnte)

Und ich hatte gehofft, mir das überlegen sparen zu können ;-) Na gut,
dann probiere ich jetzt weiter rum...

Noch einen schönen Tag und nochmal vielen Dank
Sven

[Henry Habermacher [MVP Access]]

Hallo Sven

Post by Sven Seynsche
Die Koordinaten habe ich in einer Tabelle, die bei der Abfrage
eingebunden ist. Habe das also geändert, so dass auch gleich die
Koordinaten vorliegen und nicht erst per lookup geholt werden müssen.

Aha, siehst Du, also doch DLookups() einfach irgendwo versteckt. Dacht'
ich's mir doch.

Post by Sven Seynsche

Post by Henry Habermacher [MVP Access]

Post by Sven Seynsche

Post by Henry Habermacher [MVP Access]
Nachdem Du nun bereits die halbe Zeit eingespart hast, hoffe ich,
dass diese Tipps nochmals die Zeit auf ca. 1/4 reduzieren werden,
so dass Du dann statt bei 80 Sekunden bei 5-8 Sekunden bist, wenn
Du auf die letzte Seite wechselst ;-)

Ja, stimmt genau: 5 Sekunden! Deine Kristallkugel ist wirklich gut
:;-)))

Erfahrungswerte ;-)

Trotzdem freut es mich, das wäre eine Verbesserung der Performance von 80s
auf 5s, also auf ca. 6% der ursprünglichen Antwortzeit (1/16-tel der
Antwortzeit). Ich würde das mal als Erfolg werten :-)

Post by Sven Seynsche

Post by Henry Habermacher [MVP Access]

Post by Sven Seynsche
Gibt es eigentlich ein Tool, dass solche Performance-Bremsen
(zumindest die offensichtlichen) findet? Die Acc-eigene Aalyse hat
mir da selbstredend nichts gezeigt.

Nein, mir ist keines bekannt. Es gibt zwar WhitePapers (ich glaube
mal bei MS in der KB eines gesehen zu haben bezüglich Jet
Performance), aber der rest ist halt einfach Erfahrungssache und
probieren, probieren, probieren (und zwischen durch mal überlegen,
was denn hinten dran so ablaufen könnte)

Und ich hatte gehofft, mir das überlegen sparen zu können ;-) Na gut,
dann probiere ich jetzt weiter rum...

Beim Rumprobieren lernt man ja immer dazu, also schön so weitermachen und
wenn Du nicht weiterkommst, sind wir hier ja immer für Dich da ;-)

Weiterhin viel Erfolg mit Access!

Gruss
Henry