DSum und Datum als Kriterium
Andreas
ich berechne eine laufende Summe innerhalb einer Abfrage mit der
Funktion "DomSumme" (=DSum).
DomSumme("[sngAmount]";"[tblAccountMovements]";"STR(CDBL([datDate]))
<=" & Str(ZDouble([datDate])))
sngAmount sind positve oder negative Zahlen aus der Tabelle
"tblAccountMovements".
"datDate" ist ein Datumsfeld aus derselben Tabelle.
Ich möchte, dass eine laufende Summe in chronologischer Reihenfolge,
d.h. sortiert nach "datDate" berechnet wird. Dies funktioniert
prinzipiell auch, allerdings gibt es Probleme, wenn ein Datum mehr als
1x vorkommt. Dann nämlich wird auch schon im ersten Datensatz für das
entsprechende Datum die Summe für den gesamten Tag berechnet und
angezeigt.
Beispiel:
tblAccountMovements
datDate sngAmount
01.01.09 1000
15.02.09 -200
30.06.09 5000
30.06.09 -2000
In der Abfrage erscheint dann folgendes Bild
datDate sngAmount Running total
01.01.09 1000 1000
15.02.09 -200 800
30.06.09 5000 3800
30.06.09 -2000 3800
In der dritten Zeile der Abfarge müsste aber in Wirklichkeit der Wert
5800 erscheinen, aber für den 30.06. werden für beide Datensätze +3000
(5000-2000) hinzu addiert.
Wie muss ich die Formel anpassen, damit das funktioniert?
Gruß
Andreas
Karl Donaubauer
> ich berechne eine laufende Summe innerhalb einer Abfrage mit der
> Funktion "DomSumme" (=DSum).
>
> DomSumme("[sngAmount]";"[tblAccountMovements]";"STR(CDBL([datDate]))
> <=" & Str(ZDouble([datDate])))
Einfacher w�re:
DomSumme("sngAmount";"tblAccountMovements";"datDate<=" & clng(datDate))
> sngAmount sind positve oder negative Zahlen aus der Tabelle
> "tblAccountMovements".
> "datDate" ist ein Datumsfeld aus derselben Tabelle.
>
> Ich m�chte, dass eine laufende Summe in chronologischer Reihenfolge,
> d.h. sortiert nach "datDate" berechnet wird. Dies funktioniert
> prinzipiell auch, allerdings gibt es Probleme, wenn ein Datum mehr als
> 1x vorkommt. Dann n�mlich wird auch schon im ersten Datensatz f�r das
> entsprechende Datum die Summe f�r den gesamten Tag berechnet und
> angezeigt.
>
> Beispiel:
>
> tblAccountMovements
>
> datDate sngAmount
> 01.01.09 1000
> 15.02.09 -200
> 30.06.09 5000
> 30.06.09 -2000
>
> In der Abfrage erscheint dann folgendes Bild
>
> datDate sngAmount Running total
> 01.01.09 1000 1000
> 15.02.09 -200 800
> 30.06.09 5000 3800
> 30.06.09 -2000 3800
>
> In der dritten Zeile der Abfarge m�sste aber in Wirklichkeit der Wert
> 5800 erscheinen, aber f�r den 30.06. werden f�r beide Datens�tze +3000
> (5000-2000) hinzu addiert.
>
> Wie muss ich die Formel anpassen, damit das funktioniert?
Du brauchst ein weiteres Unterscheidungskriterium, denn das
Tagesdatum ist nunmal gleich f�r beide Datens�tze.
Gibt es in tblAccountMovements keinen Prim�rschl�ssel oder
sonstiges eindeutiges Feld? So etwas br�uchtest du als
zus�tzliches Sortierfeld in der Abfrage und Kriterium im Ausdruck.
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f�r Accessler 27./28.2.2010
Andreas
> Einfacher w re:
>
> DomSumme("sngAmount";"tblAccountMovements";"datDate<=" & clng(datDate))
So hatte ich das zuerst, hatte aber ausprobiert, ob mich ein Datum in
Kombination mit einer Uhrzeit weiterbringt. Das hat aber irgendwie
nicht funktioniert.
> Du brauchst ein weiteres Unterscheidungskriterium, denn das
> Tagesdatum ist nunmal gleich f r beide Datens tze.
> Gibt es in tblAccountMovements keinen Prim rschl ssel oder
> sonstiges eindeutiges Feld? So etwas br uchtest du als
> zus tzliches Sortierfeld in der Abfrage und Kriterium im Ausdruck.
Ich hatte schon mit einem zusätzlichen ID Feld (Autonumber)
gearbeitet. Hier ist das Problem, dass wenn ich nachträglich ein Datum
eintrage, welches in der Vergangenheit liegt (und evtl. schon
vorhanden ist), funktioniert meine Sortierung nach dem Datum nicht
mehr, da ja Autonumber dann trotzdem die höchste Zahl hat. Ich brauche
die laufende Summe aber auf jeden Fall in chronologischer Reihenfolge.
Karl Donaubauer
> Karl Donaubauer wrote:
>> Einfacher w re:
>>
>> DomSumme("sngAmount";"tblAccountMovements";"datDate<=" &
>> clng(datDate))
>
> So hatte ich das zuerst, hatte aber ausprobiert, ob mich ein Datum in
> Kombination mit einer Uhrzeit weiterbringt. Das hat aber irgendwie
> nicht funktioniert.
Wie hat sich "irgendwie nicht funktioniert" genau ge锟絬锟絜rt?
Wurde nicht richtig sortiert? Wenn ja, nenne Beispiele.
Der Ausdruck w锟絩e:
DomSumme("sngAmount";"tblAccountMovements";"datDate<=" &
str(cdbl(datDate)))
>> Du brauchst ein weiteres Unterscheidungskriterium, denn das
>> Tagesdatum ist nunmal gleich f r beide Datens tze.
>> Gibt es in tblAccountMovements keinen Prim rschl ssel oder
>> sonstiges eindeutiges Feld? So etwas br uchtest du als
>> zus tzliches Sortierfeld in der Abfrage und Kriterium im Ausdruck.
>
> Ich hatte schon mit einem zus锟絫zlichen ID Feld (Autonumber)
> gearbeitet. Hier ist das Problem, dass wenn ich nachtr锟絞lich ein Datum
> eintrage, welches in der Vergangenheit liegt (und evtl. schon
> vorhanden ist), funktioniert meine Sortierung nach dem Datum nicht
> mehr, da ja Autonumber dann trotzdem die h锟絚hste Zahl hat. Ich brauche
> die laufende Summe aber auf jeden Fall in chronologischer Reihenfolge.
Wenn du eine Uhrzeit und keine gleichzeitigen Datens锟絫ze hast,
dann reicht diese as wie o.a.
Bei Gleichzeitigkeiten oder Nur-Datum kannst du die Id, wie
gesagt, als zweites Sortierfeld und Kriterium nach dem Datum
verwenden, also nachrangig in der Sortierung.
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f锟絩 Accessler 27./28.2.2010
Andreas
> Bei Gleichzeitigkeiten oder Nur-Datum kannst du die Id, wie
> gesagt, als zweites Sortierfeld und Kriterium nach dem Datum
> verwenden, also nachrangig in der Sortierung.
Wie genau müsste die Formel denn dann aussehen?
DomSumme("[sngAmount]";"[tblAccountMovements]";"[datDate]<=" & ZLong
([datDate]) & "And [ID]<=" & [ID])
Diese Formel, so wie ich es jetzt versucht habe, funktioniert nicht
korrekt. Die ID ist nicht wirklich zweitrangig, sondern erscheint mir
gleichberechtigt zu sein. Was muss ich ändern?
Andreas
Ich habe jetzt in tblAccountMovements noch das Feld "datTime"
eingefügt, damit ich Datum und Uhrzeit sauber trennen kann. Wie müsste
dann die Formel aussehen, wenn ich datTime als zweites
Sortierkriterium verwenden möchte? Mit welcher Formel wandel ich eine
Uhrzeit in eine fortlaufende Zahl um (analog zu CLng)?
Siegfried Schmidt
> DomSumme("[sngAmount]";"[tblAccountMovements]";"[datDate]<=" & ZLong
> ([datDate]) & "And [ID]<=" & [ID])
>
> Diese Formel, so wie ich es jetzt versucht habe, funktioniert nicht
> korrekt. Die ID ist nicht wirklich zweitrangig, sondern erscheint mir
> gleichberechtigt zu sein. Was muss ich ï¿œndern?
Du kannst eine Bedingung nicht so formulieren dass sie die Rangstufe in
einer nachrangigen Sortierung abbildet. Das geht nur duch Zusammenziehung
der beiden Felder zu einem Wert, der die Rangfolge der Zeilen eindeutig
angibt.
Da Access keinen numerischen Datentyp mit dem nï¿œtigen Wertebereich hat
bleibt nur der Umweg ï¿œber eine Textdarstellung z.B. in der Form
yyyymmdd0000000id. Dieser Wert lï¿œsst sich dann in der Bedingung der
Summenermittlung verwenden.
Siegfried
Karl Donaubauer
>> ...
>> DomSumme("[sngAmount]";"[tblAccountMovements]";"[datDate]<=" & ZLong
>> ([datDate]) & "And [ID]<=" & [ID])
>>
>> Diese Formel, so wie ich es jetzt versucht habe, funktioniert nicht
>> korrekt. Die ID ist nicht wirklich zweitrangig, sondern erscheint mir
>
> Ich habe jetzt in tblAccountMovements noch das Feld "datTime"
> dann die Formel aussehen, wenn ich datTime als zweites
> Uhrzeit in eine fortlaufende Zahl um (analog zu CLng)?
Trennen bringt nichts, eher schon zusammenfassen.
Du hast noch immer nicht verraten, ob dir Datum und Uhrzeit nun
als Sortierkriterium reichen oder nicht. Falls ja, habe ich den
Ausdruck bereits gepostet.
Falls nein, sollte - wie Siegfried schon schrieb - ein kombiniertes,
berechnetes Feld aus Datum, Uhrzeit und Id helfen. Prinzip:
Format(datTime,'yyyymmddhhnn') & Format(ID,'0000000000')
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f�r Accessler 27./28.2.2010
Andreas
> Falls nein, sollte - wie Siegfried schon schrieb - ein kombiniertes,
> berechnetes Feld aus Datum, Uhrzeit und Id helfen. Prinzip:
>
So langsam verzweifle ich wirklich. Habe jetzt innerhalb der Abfrage
ein berechnetes Feld eingefügt:
Format([datDate];'jjjjmmtt') & Format([ID];'00000')
Damit funktioniert die Sortierung auch so, wie ich es mir vorstelle.
Gleiche Tage sind jetzt kein Problem mehr. Allerdings kriege ich die
Formel für die laufende Summe nicht mehr hin. Die Spalte "Running
total" bleibt komplett leer. Meine Formel sieht jetzt so aus:
DomSumme("[sngAmount]";"[tblAccMovements]";"[IDSub]<=" & [IDSub])
Wie muss ich denn die Formel anpassen, damit ich die Werte des
Textfeldes IDSub in der Berechnung verwenden kann?
Danke für die Hilfe!
Gruß
Karl Donaubauer
> Karl Donaubauer wrote:
>> Falls nein, sollte - wie Siegfried schon schrieb - ein
>> kombiniertes, berechnetes Feld aus Datum, Uhrzeit und Id helfen.
>> Prinzip:
>>
>> IDSub: Format(datTime,'yyyymmddhhnn') & Format(ID,'0000000000')
>
> So langsam verzweifle ich wirklich. Habe jetzt innerhalb der Abfrage
>
> Format([datDate];'jjjjmmtt') & Format([ID];'00000')
Dir ist klar, dass 5 Stellen nur f锟絩 die ersten 99999 IDs reichen?
> Damit funktioniert die Sortierung auch so, wie ich es mir vorstelle.
> Gleiche Tage sind jetzt kein Problem mehr.
Die mehrfache Nachfrage nach der Uhrzeit willst du offensichtlich
nicht beantworten. Ich wiederhole den Hinweis trotzdem nochmal,
dass ein Feld mit Datum+Uhrzeit die "normale" und effizientere
Methode der Sortierung w锟絩e.
> Allerdings kriege ich die
> Formel f锟絩 die laufende Summe nicht mehr hin. Die Spalte "Running
> total" bleibt komplett leer. Meine Formel sieht jetzt so aus:
>
> DomSumme("[sngAmount]";"[tblAccMovements]";"[IDSub]<=" & [IDSub])
>
> Wie muss ich denn die Formel anpassen, damit ich die Werte des
> Textfeldes IDSub in der Berechnung verwenden kann?
Du hast nicht geschrieben, wie das neue, kombinierte Feld hei锟絫.
Daher wieder nur das Prinzip:
DomSumme("sngAmount";"tblAccMovements";
"Format(datDate,'jjjjmmtt') & Format(ID;'00000')<='" & [NeuesSortierFeld] &
"'")
Wobei mir z.B. nicht klar ist, ob "ID" und "IDSub" das selbe Feld sind.
Wenn du es nicht hinbekommst, dann poste den SQL-Text der Abfrage.
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f锟絩 Accessler 27./28.2.2010
Andreas
> > Format([datDate];'jjjjmmtt') & Format([ID];'00000')
>
Ja, das ist für meine Zwecke jedoch mehr als ausreichend.
> Die mehrfache Nachfrage nach der Uhrzeit willst du offensichtlich
> nicht beantworten. Ich wiederhole den Hinweis trotzdem nochmal,
> dass ein Feld mit Datum+Uhrzeit die "normale" und effizientere
> Methode der Sortierung wäre.
Ich habe die Aufnahme der Uhrzeit verworfen, da die Information für
meine eigentlichen Zwecke irrelevant ist. Da finde ich die Idee, eine
Auto-ID für die Sortierung hinzuzunehmen besser, dann muss ich die
Uhrzeit nämlich nicht immer eingeben.
Das Feld "ID" aus der Tabelle tblAccMovements ist ein AutoWert.
In der Abfrage habe ich dann das berechnete Feld "IDSub" mit der
Formel
IDSub: Format([datDate];'jjjjmmtt') & Format([ID];'00000')
Dieses Feld ist das neue Sortierfeld.
Die Formel für die laufende Summe hatte ich dann ja schon gepostet:
Total balance: DomSumme("[sngAmount]";"[tblAccMovements]";"[IDSub]<="
& [IDSub])
Damit funktioniert es nicht. Auch mit folgender Formel habe ich keinen
Erfolg:
Total balance 2: DomSumme("[sngAmount]";"[tblAccMovements]";"Format
([datDate];'jjjjmmtt') & Format([ID];'00000')<=" & [IDSub] & "")
> Wenn du es nicht hinbekommst, dann poste den SQL-Text der Abfrage.
SELECT tblAccMovements.datDate, Format([datDate],'yyyymmdd') & Format
([ID],'00000') AS IDSub, tblAccMovements.sngAmount, DSum
("[sngAmount]","[tblAccMovements]","format(datDate;'jjjjmmtt') & format
(ID;'00000')<=" & [IDSub]) AS [Total balance], DSum
("[sngAmount]","[tblAccMovements]","Format([datDate];'jjjjmmtt') &
Format([ID];'00000')<=" & [IDSub] & "") AS [Total balance 2]
FROM tblAccMovements
ORDER BY Format([datDate],'yyyymmdd') & Format([ID],'00000');
Danke und guten Rutsch ins neue Jahr!!
Karl Donaubauer
> Karl Donaubauer wrote:
> Ich habe die Aufnahme der Uhrzeit verworfen, da die Information f�r
> meine eigentlichen Zwecke irrelevant ist. Da finde ich die Idee,
> die Uhrzeit n�mlich nicht immer eingeben.
Die aktuelle Uhrzeit gibt man nicht selber ein, sondern l�sst
sie von Access eintragen. z.B. in einem Datumsfeld durch den
Standardwert: =Now()
> ...
> Die Formel f�r die laufende Summe hatte ich dann ja schon gepostet:
>
> Total balance:
> DomSumme("[sngAmount]";"[tblAccMovements]";"[IDSub]<=" & [IDSub])
>
> Damit funktioniert es nicht.
Klar, denn ngung "[IDSub]<=" &... hei�t, dass IDSub ein Feld in
tblAccMovements sein m�sste.
> Auch mit folgender Formel habe ich
> keinen Erfolg:
>
> Total balance 2: DomSumme("[sngAmount]";"[tblAccMovements]";"Format
> ([datDate];'jjjjmmtt') & Format([ID];'00000')<=" & [IDSub] & "")
> ...
Hoppala, der Zug, in dem ich meinen letzten Vorschlag schrieb,
hat eindeutig zu viel ger�ttelt, denn ich habe deutsche Datumsk�rzel
verwendet, wo englische notwendig w�ren und ein Semikolon hat
�berlebt. Au�erdem hast du die beiden Apostrophe weggelassen.
Versuche es damit (am besten per Zwischenablage kopieren und dann
den Zeilenumbruch rausnehmen):
TotalBalance2: DomSumme("sngAmount";"tblAccMovements";
"Format(datDate,'yyyymmdd') & Format(ID,'00000')<='" & [IDSub] & "'")
Falls es damit auch nicht funktioniert, dann schildere genau wie
sich das Nicht-Funktionieren ausdr�ckt. Welcher Fehler oder
welche Fehlermeldung tritt auf?
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f�r Accessler 27./28.2.2010
Andreas
> Andreas wrote:
> > Karl Donaubauer wrote:
> Hoppala, der Zug, in dem ich meinen letzten Vorschlag schrieb,
> hat eindeutig zu viel gerüttelt, denn ich habe deutsche Datumskürzel
> verwendet, wo englische notwendig wären und ein Semikolon hat
> überlebt. Außerdem hast du die beiden Apostrophe weggelassen.
> Versuche es damit (am besten per Zwischenablage kopieren und dann
> den Zeilenumbruch rausnehmen):
>
> TotalBalance2: DomSumme("sngAmount";"tblAccMovements";
> "Format(datDate,'yyyymmdd') & Format(ID,'00000')<='" & [IDSub] & "'")
Damit hat es jetzt funktioniert. Ich bin begeistert. Herzlichen Dank!
Gruß
Andreas
Andreas
habe mir aus Neugier doch noch mal die Mühe gemacht und mein
Sortierkriterium mittels Datum/Uhrzeit-Feld erstellt.
@Karl
Die Formel, die du mir für die laufende Summe genannt hattest,
funktioniert bei mir jetzt auch. Ich weiß nicht, was ich da vorher für
einen Fehler hatte.
Wie dem auch sei, die nächste Aufgabe besteht nun darin, in einer
neuen Spalte in jedem Datensatz den bis dahin größten Wert der Spalte
mit der laufenden Summe (DomSumme) zu ermitteln. Dafür habe ich die
DomMax-Funktion benutzt. Das Kriterium ist dasselbe wie bei der Dom-
Summe-Funktion, d.h. ich gehe über das Datum/Uhrzeit Feld.
Jetzt kommt's: bis zu einem bestimmten Datensatz gibt die Funktion
auch das richtige Ergebnis aus, ab dann wird ein falscher Maximalwert
angezeigt. Ich kann mir nicht erklären, woran das liegt.
Der SQL Code der Abfrage "qryAccMovements" sieht folgendermaßen aus:
SELECT qryAccMovementsUnion.datDate, qryAccMovementsUnion.sngAmount,
Format(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
(CDbl([datDate]))),"Currency") AS [Total balance], DMax("[Total
balance]","[qryAccMovements]","datDate<=" & Str(CDbl([datDate]))) AS
[Max total balance]
FROM qryAccMovementsUnion
ORDER BY qryAccMovementsUnion.datDate;
Die laufende Summe in Spalte "Total balance" wird aus der Spalte
"sngAmount" in der Abfrage "qryAccMovementsUnion" erzeugt. Die DomMax-
Funktion in der Spalte "Max total balance" bezieht sich dann jedoch
auf die soeben erzeugte laufende Summe in der Abfrage
"qryAccMovements".
Kann es sein, dass der Mix der Abfragen im Code für Schwierigkeiten
sorgt?
Gruß
Andreas
Karl Donaubauer
> ...
> die n�chste Aufgabe besteht nun darin, in einer
> neuen Spalte in jedem Datensatz den bis dahin gr��ten Wert der Spalte
> mit der laufenden Summe (DomSumme) zu ermitteln. Daf�r habe ich die
> DomMax-Funktion benutzt. Das Kriterium ist dasselbe wie bei der Dom-
>
> Jetzt kommt's: bis zu einem bestimmten Datensatz gibt die Funktion
> auch das richtige Ergebnis aus, ab dann wird ein falscher Maximalwert
>
> Der SQL Code der Abfrage "qryAccMovements" sieht folgenderma�en aus:
>
> SELECT qryAccMovementsUnion.datDate, qryAccMovementsUnion.sngAmount,
> Format(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
> (CDbl([datDate]))),"Currency") AS [Total balance], DMax("[Total
> balance]","[qryAccMovements]","datDate<=" & Str(CDbl([datDate]))) AS
> [Max total balance]
> FROM qryAccMovementsUnion
> ORDER BY qryAccMovementsUnion.datDate;
>
> Die laufende Summe in Spalte "Total balance" wird aus der Spalte
> "sngAmount" in der Abfrage "qryAccMovementsUnion" erzeugt. Die DomMax-
> Funktion in der Spalte "Max total balance" bezieht sich dann jedoch
> auf die soeben erzeugte laufende Summe in der Abfrage
> "qryAccMovements".
Mich wundert, dass du �berhaupt Ergebnisse bekommst, wenn du
dich in einer D-Funktion auf ein Feld beziehst, das selbst erst per
D-Funktion berechnet werden muss. Bei einem kurzen Test blieb
bei mir die DMax-Spalte erwartungsgem�� leer.
Es sollte also eigentlich eine zweite Abfrage n�tig sein, die auf
der qryAccMovements aufbaut.
Welche Access-Version verwendest du denn?
Was die unerwarteten Ergebnisse betrifft, so kommen die
wahrscheinlich dadurch, dass das Ergebnis die DSum-Spalte
als Text behandelt wird - mit oder ohne Format-Funktion - und
daher f�r DMax z.B. "1000" kleiner ist als "99". Versuche mal statt
Format(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
(CDbl([datDate]))),"Currency") AS [Total balance],
das hier:
ccur(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
(CDbl([datDate])))) AS [Total balance],
Andreas
> Mich wundert, dass du berhaupt Ergebnisse bekommst, wenn du
> dich in einer D-Funktion auf ein Feld beziehst, das selbst erst per
> D-Funktion berechnet werden muss. Bei einem kurzen Test blieb
> bei mir die DMax-Spalte erwartungsgem leer.
> Es sollte also eigentlich eine zweite Abfrage n tig sein, die auf
> der qryAccMovements aufbaut.
> Welche Access-Version verwendest du denn?
Teste gerade die Access 2010 Beta Version. Welche Version nutzt du?
>
> Was die unerwarteten Ergebnisse betrifft, so kommen die
> wahrscheinlich dadurch, dass das Ergebnis die DSum-Spalte
> als Text behandelt wird - mit oder ohne Format-Funktion - und
> daher f r DMax z.B. "1000" kleiner ist als "99". Versuche mal statt
>
> Format(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
> (CDbl([datDate]))),"Currency") AS [Total balance],
>
> das hier:
>
> ccur(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
> (CDbl([datDate])))) AS [Total balance],
Volltreffer. Mit der Umwandlung in Currency funktioniert es. Es ist
auch nicht nötig eine zweite Abfrage zu erstellen.
Danke und Gruß
Andreas
Karl Donaubauer
> Karl Donaubauer wrote:
>> Mich wundert, dass du berhaupt Ergebnisse bekommst, wenn du
>> dich in einer D-Funktion auf ein Feld beziehst, das selbst erst per
>> D-Funktion berechnet werden muss. Bei einem kurzen Test blieb
>> bei mir die DMax-Spalte erwartungsgem leer.
>> Es sollte also eigentlich eine zweite Abfrage n tig sein, die auf
>> der qryAccMovements aufbaut.
>> Welche Access-Version verwendest du denn?
>
> Teste gerade die Access 2010 Beta Version. Welche Version nutzt du?
Joo, h�tte ich auch gleich angeben k�nnen. :-)
Ich habe es mit Access 2003 probiert.
>> ...
>> ccur(DSum("[sngAmount]","[qryAccMovementsUnion]","datDate<=" & Str
>> (CDbl([datDate])))) AS [Total balance],
>
> Volltreffer. Mit der Umwandlung in Currency funktioniert es. Es ist
> auch nicht n�tig eine zweite Abfrage zu erstellen.
Es hat in der Vergangenheit auch schon �nderungen beim Caching
von Berechnungen bzw. Funktionsaufrufen in Abfragen gegeben.
Durchaus m�glich, dass es mit 2007 oder 2010 wieder welche gab.
Andreas
ich komme noch mal zurück auf mein Anliegen bzgl. der Bildung einer
laufenden Summe mittels DomSumme.
Vom Ansatz her liefert mir diese Vorgehensweise genau die Ergebnisse,
die ich haben will. Allerdings läuft die Abfrage extrem langsam,
sobald ich ein paar mehr Daten innerhalb der Abfrage verarbeite. Ich
habe jetzt ca. 110 Datensätze und man kann mit der Abfrage nicht mehr
arbeiten. Es dauert sehr lange bis sie überhaupt geladen ist und an
scrollen ist gar nicht zu denken. Access hängt sich dann praktisch
auf.
Woran liegt das? Liegt das daran, dass für jeden Datensatz die Summe
von Anfang an erneut berechnet werden muss?
Gibt es da Optimierungsmöglichkeiten?
Gruß
Andreas
Karl Donaubauer
> ich komme noch mal zur�ck auf mein Anliegen bzgl. der Bildung einer
> laufenden Summe mittels DomSumme.
> Vom Ansatz her liefert mir diese Vorgehensweise genau die
> langsam, sobald ich ein paar mehr Daten innerhalb der Abfrage
> Abfrage nicht mehr arbeiten. Es dauert sehr lange bis sie �berhaupt
> geladen ist und an scrollen ist gar nicht zu denken. Access h�ngt
> sich dann praktisch auf.
>
> Woran liegt das? Liegt das daran, dass f�r jeden Datensatz die Summe
> von Anfang an erneut berechnet werden muss?
Nat�rlich bremst die DSumme, aber bei 110 Datens�tzen sollte das
noch nicht so arg sein.
Ich vermute eher, dass es daran liegt, dass du irgendwann die Basis
der Abfrage und der DSum-Funktion von "tblAccountMovements" auf
"qryAccMovementsUnion" ge�ndert hast. Also von einer Tabelle auf
eine Abfrage.
Das war sicher kein Performancegewinn.
Umso mehr, wenn das auch noch wirklich eine Union-Abfrage ist,
wie der Name suggeriert.
Was mir noch auff�llt im Thread ist, dass du nach einer bzw. zwei
berechneten Spalte sortiert hast. Urspr�nglich war das:
> ORDER BY Format([datDate],'yyyymmdd') & Format([ID],'00000');
So etwas solltest du vermeiden, wenn m�glich. In diesem Beispiel
ist die Sortierung direkt auf die zwei Felder besser. Also:
ORDER BY datDate, ID
Diese zwei Felder sollten zudem in der Tabelle indiziert sein.
Andreas
> Natürlich bremst die DSumme, aber bei 110 Datensätzen sollte das
> noch nicht so arg sein.
>
> Ich vermute eher, dass es daran liegt, dass du irgendwann die Basis
> der Abfrage und der DSum-Funktion von "tblAccountMovements" auf
> "qryAccMovementsUnion" geändert hast. Also von einer Tabelle auf
> eine Abfrage.
>
> Das war sicher kein Performancegewinn.
> Umso mehr, wenn das auch noch wirklich eine Union-Abfrage ist,
> wie der Name suggeriert.
Ich versuche mal den relevanten Teil der Datenbankstruktur
aufzuzeigen. Generell handelt es sich um eine Datenbank um meine
Börsengeschäfte auszuwerten.
tblTrades: Hier werden alle Daten für die einzelnen Geschäfte erfasst
(derzeit 110 Datensätze); Feld "datDateExit" ist indiziert.
tblAccMovements: Hier werden Ein- und Auszahlung auf mein Handelskonto
erfasst (derzeit 8 Datensätze)
qryP&L: Hier wird der Gewinn/Verlust für die einzelnen Geschäfte auf
Basis von tblTrades errechnet. Auch eine laufende Summe der Gewinne
wird mitgeführt. (Läuft schnell und flüssig)
qryAccMovementsCash: Basiert auf tblAccMovements und berechnet die
laufende Summe (=Kontostand ohne Trades)
qryAccMovementsTrades: Basiert auf qryP&L und berechnet laufende Summe
(=Gesamtergebnis aller Trades zu jedem Zeitpunkt); Abfrage ist nötig,
um qryAccMovementsCash und qryAccMovementsTrades zu einer UNION
Abfrage zusammen zu führen. (Läuft quelend langsam)
qryAccMovementsUnion: UNION-Abfrage aus qryAccMovementsCash und
qryAccMovementsTrades; gibt mir den laufenden Kontostand zu jedem
Zeitpunkt inkl. Handelsergebnisse und Ein- und Auszahlungen an
(Kontostand des Handelskontos) (Läuft natürlich auch quelend langsam)
>
> Was mir noch auffällt im Thread ist, dass du nach einer bzw. zwei
> berechneten Spalte sortiert hast. Ursprünglich war das:
>
> > ORDER BY Format([datDate],'yyyymmdd') & Format([ID],'00000');
Vielleicht hatte ich es tatsächlich mal so sortiert, jetzt aber nicht
mehr. Nutze jetzt auch nicht mehr ein kombiniertes Sortierkriterium,
sondern nur noch "datDate". Dies beinhaltet jetzt auch die Uhrzeit.
Das war ja mal dein ursprünglicher Vorschlag.
Falls du noch SQL Code sehen möchtest, sag Bescheid.
Gruß
Karl Donaubauer
> Karl Donaubauer wrote:
>> Ich vermute eher, dass es daran liegt, dass du irgendwann die Basis
>> der Abfrage und der DSum-Funktion von "tblAccountMovements" auf
>> eine Abfrage.
>>
>> Das war sicher kein Performancegewinn.
>> Umso mehr, wenn das auch noch wirklich eine Union-Abfrage ist,
>> wie der Name suggeriert.
>
> Ich versuche mal den relevanten Teil der Datenbankstruktur
> aufzuzeigen. Generell handelt es sich um eine Datenbank um meine
>
> tblTrades: Hier werden alle Daten f�r die einzelnen Gesch�fte
> erfasst (derzeit 110 Datens�tze); Feld "datDateExit" ist indiziert.
>
> tblAccMovements: Hier werden Ein- und Auszahlung auf mein
>
> qryP&L: Hier wird der Gewinn/Verlust f�r die einzelnen Gesch�fte auf
> Basis von tblTrades errechnet. Auch eine laufende Summe der Gewinne
>
> qryAccMovementsCash: Basiert auf tblAccMovements und berechnet die
> laufende Summe (=Kontostand ohne Trades)
>
> qryAccMovementsTrades: Basiert auf qryP&L und berechnet laufende
> Summe (=Gesamtergebnis aller Trades zu jedem Zeitpunkt); Abfrage
> einer UNION Abfrage zusammen zu f�hren. (L�uft quelend langsam)
>
> qryAccMovementsUnion: UNION-Abfrage aus qryAccMovementsCash und
> qryAccMovementsTrades; gibt mir den laufenden Kontostand zu jedem
> Zeitpunkt inkl. Handelsergebnisse und Ein- und Auszahlungen an
> langsam)
> ...
Ich kann ohne n�here Kenntnis deiner Daten und Anforderungen
nicht beurteilen, was von diesen Dingen notwendig ist oder etwa
schon in der Tabellenstruktur anders aussehen sollte.
Klar ist, dass der Aufbau mit Abfragen, Union darauf, D-Funktionen
quasi auf D-Funktionen etc. performancetechnisch katastrophal ist.
Die zwei �blichen Varianten an Notbehelf in solchen Situationen sind
"Arbeitstabellen" und das Speichern von berechneten Daten.
"Arbeitstabellen" dienen zum Speichern von (Zwischen-) Ergebnissen,
damit darauf folgende Berechnungen oder z.B. ein Bericht schneller
werden. Die Tabellen werden immer wieder komplett geleert und
dann mit den Ergebnissen von Abfragen gef�llt. Du k�nntest testen,
an welchen Stellen das bei dir am meisten bringt.
Berechnete Daten speichern macht man aus Performancegr�nden
auch gelegentlich. Du musst dann halt sicher sein, dass sich die
Basis der Berechnungen nie �ndert oder die Neuberechnung
sicherstellen, falls das doch passiert.
Andreas
> Andreas wrote:
> > Karl Donaubauer wrote:
> > ...
> >> Ich vermute eher, dass es daran liegt, dass du irgendwann die Basis
> >> der Abfrage und der DSum-Funktion von "tblAccountMovements" auf
> >> eine Abfrage.
>
> >> Das war sicher kein Performancegewinn.
> >> Umso mehr, wenn das auch noch wirklich eine Union-Abfrage ist,
> >> wie der Name suggeriert.
>
> > Ich versuche mal den relevanten Teil der Datenbankstruktur
> > aufzuzeigen. Generell handelt es sich um eine Datenbank um meine
>
> > tblTrades: Hier werden alle Daten für die einzelnen Geschäfte
>
> > tblAccMovements: Hier werden Ein- und Auszahlung auf mein
>
> > qryP&L: Hier wird der Gewinn/Verlust für die einzelnen Geschäfte auf
> > Basis von tblTrades errechnet. Auch eine laufende Summe der Gewinne
>
> > laufende Summe (=Kontostand ohne Trades)
>
> > qryAccMovementsTrades: Basiert auf qryP&L und berechnet laufende
> > Summe (=Gesamtergebnis aller Trades zu jedem Zeitpunkt); Abfrage
> > einer UNION Abfrage zusammen zu führen. (Läuft quelend langsam)
>
> > qryAccMovementsUnion: UNION-Abfrage aus qryAccMovementsCash und
> > qryAccMovementsTrades; gibt mir den laufenden Kontostand zu jedem
> > Zeitpunkt inkl. Handelsergebnisse und Ein- und Auszahlungen an
> > langsam)
> > ...
>
> Ich kann ohne nähere Kenntnis deiner Daten und Anforderungen
> nicht beurteilen, was von diesen Dingen notwendig ist oder etwa
> schon in der Tabellenstruktur anders aussehen sollte.
>
> Klar ist, dass der Aufbau mit Abfragen, Union darauf, D-Funktionen
> quasi auf D-Funktionen etc. performancetechnisch katastrophal ist.
> "Arbeitstabellen" und das Speichern von berechneten Daten.
>
> "Arbeitstabellen" dienen zum Speichern von (Zwischen-) Ergebnissen,
> damit darauf folgende Berechnungen oder z.B. ein Bericht schneller
> werden. Die Tabellen werden immer wieder komplett geleert und
> an welchen Stellen das bei dir am meisten bringt.
>
> auch gelegentlich. Du musst dann halt sicher sein, dass sich die
> sicherstellen, falls das doch passiert.
Hmmm, ich befürchte fast, dass z.B. die Berechung des Gewinn/Verlustes
in "tblTrades" nicht möglich ist, da für diese Berechnung auch noch
Informationen aus tblSecurities nötig sind. Und wenn ich es richtig
verstehe, so kann ich innerhalb eines berechneten Feldes in
"tblTrades" nicht auf ein Feld in "tblSecurities" zugreifen.
Habe aber probeweise mal den Gewinn/Verlust in "tblTrades" berechnet,
und zwar ohne die nötigen Informationen aus "tblSecurities". Damit ist
die Berechnung an sich zwar falsch, aber wenn ich jetzt eine Abfrage
inkl. DomSumme auf "tblTrades" mache, läuft die Sache ziemlich
schnell. Es liegt also wirklich an DomSumme auf DomSumme, wie du schon
beschrieben hast.
Jetzt muss ich mir Gedanken über meine Datenbankstruktur machen, wobei
ich der Meinung bin, dass die aktuelle Struktur vom Aufbau her
vollkommen Sinn macht. Die Trennung der Informationen in tblTrades und
tblSecurities möchte ich auf jeden Fall beibehalten, weil es
inhaltlich zwei völlig verschiedene Themen sind.
Kann man die Abfrage, wie ich sie bis dato hatte, d.h. DomSumme auf
DomSumme nicht zufällig per VBA erstellen und damit beschleunigen?
Gruß
Andreas
Karl Donaubauer
> Karl Donaubauer wrote:
>>> ...
>> damit darauf folgende Berechnungen oder z.B. ein Bericht schneller
>> werden. Die Tabellen werden immer wieder komplett geleert und
>> an welchen Stellen das bei dir am meisten bringt.
>>
>> auch gelegentlich. Du musst dann halt sicher sein, dass sich die
>> sicherstellen, falls das doch passiert.
>
> in "tblTrades" nicht m�glich ist, da f�r diese Berechnung auch noch
> Informationen aus tblSecurities n�tig sind. Und wenn ich es richtig
> verstehe, so kann ich innerhalb eines berechneten Feldes in
> "tblTrades" nicht auf ein Feld in "tblSecurities" zugreifen.
>
> Habe aber probeweise mal den Gewinn/Verlust in "tblTrades" berechnet,
> die Berechnung an sich zwar falsch, aber wenn ich jetzt eine Abfrage
> schnell. Es liegt also wirklich an DomSumme auf DomSumme, wie du schon
> beschrieben hast.
Es wird nicht so recht klar, was
> den Gewinn/Verlust in "tblTrades" berechnet
bedeutet und warum du Probleme mit der Datenbeschaffung aus
einer zweiten Tabelle hast.
Wenn du nicht zuf�llig mit der Beta von A10 arbeitest, dann kannst
du in Tabellen nichts berechnen. Im Normalfall wandelt man einfach
die Auswahlabfrage, die vorher auf Basis aller notwendigen Daten
und Tabellen die Berechnung gemacht hat, in eine Aktualisierungsabfrage
und schreibt das Ergebnis der Berechnung in die Zieltabelle.
> ...
> Kann man die Abfrage, wie ich sie bis dato hatte, d.h. DomSumme auf
> DomSumme nicht zuf�llig per VBA erstellen und damit beschleunigen?
Naa.
Wie geschrieben: Wenn das mit dem Speichern der berechneten Werte
aus irgenwelchen triftigen Gr�nden nicht klappt, dann verwende halt
Arbeitstabellen zum Zwischenspeichern der Berechnungen.
Wichtig beim Entscheiden �ber das richtige Vorgehen ist auch,
wie und wof�r die Ergebnisse der Abfragen verwendet werden sollen.
Zum direkten Ansehen der Daten oder als Datenherkunft von
Formularen oder Berichten?
--
Servus
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com
Andreas
> Es wird nicht so recht klar, was> den Gewinn/Verlust in "tblTrades" berechnet
>
> bedeutet und warum du Probleme mit der Datenbeschaffung aus
> einer zweiten Tabelle hast.
>
> Wenn du nicht zuf llig mit der Beta von A10 arbeitest, dann kannst
> du in Tabellen nichts berechnen. Im Normalfall wandelt man einfach
> die Auswahlabfrage, die vorher auf Basis aller notwendigen Daten
> und Tabellen die Berechnung gemacht hat, in eine Aktualisierungsabfrage
> und schreibt das Ergebnis der Berechnung in die Zieltabelle.
Ich nutze die Beta Version von Access 2010 :-)
Damit kann ich innerhalb einer Tabelle ein berechnetes Feld anlegen,
allerdings darf dieses berechnete Feld nur auf Felder innerhalb der
Tabelle zugreifen. Das Einbringen von Feldern aus anderen Tabellen ist
nicht möglich.
Ich hatte also tatsächlich zuerst probiert, den Gewinn und Verlust in
der eigentlichen Quell-Tabelle "tblTrades" zu berechnen. Das ging aber
nicht, da ich halt noch ein Feld aus "tblSecurities" benötige.
Dein Hinweis mit der Aktualisierungsabfrage war gut. Ich habe jetzt
zwar keine Aktualisierungsabfrage, sondern eine "Tabelle erstellen"-
Abfrage. Aber das meintest du vermutlich letztendlich auch, oder?
Zumindest habe ich so aus "qryP&L" eine Tabelle gemacht. In dieser
Tabelle ist jetzt gleich auch DomSumme auf DomSumme gelandet. Somit
basiert meine UNION-Abfrage jetzt auf zwei Tabellen ohne eine einzige
Berechnung, was zu einem sehr schönen Geschwindigkeitsschub geführt
hat.
Vielen Dank für die Hilfe!
Gruß
Andreas