PDA

Vollständige Version anzeigen : Datepart problem


Jahush
23.01.2008, 14:41
hallo, ich möchte in einer abfrage ein feld haben indem ich werte anch diesem beispiel habe (zb für das heutige datum):
20080123
mir steht im prinzip nur ein feld in dem ein datum eingespeichert ist zur verfügung, also in dem beispiel wäre es der 23.01.2008.

meine idee war es
mada: datepart("yyyy";[datum])*10000 + datepart("m";[datum])*100+ datepart("ww";[datum])

nur irgendwie macht access sobald ich die spalte der abfrage in der ich das geschrieben habe automatisch aus oben stehendem soetwas:

datteil("""yyyy""";[datum])*10000

was hab ich falsch gemacht. is das eine funktion die so in der form nur ein vbscript ist und in abfragen garnet nutzbar ist? gibbt es eine andere möglichkeit auf mein gewünschtes feld zu kommen?

MfG

Scorefun
23.01.2008, 14:48
probier das mal:

format([Datum];"jjjjmmtt")

BTW: "YYYY" darfst Du nur im VBA-Code für das Jahr benutzen - in Abfragen heißt es : "JJJJ"
(genauso beim Tag : in VBA : d / in Abfragen: t)

Jahush
23.01.2008, 14:58
als was ist dieses feld nun gespeichert? ich will es als DSUm kriterium nutzen, und dafür sollte es eine zahl sein oder? woweit ich festgestellt hab kann ich kein normales datum dafür nutzen. ist das richtig so? das feld soweit wie du es mri vorgeschlagen hattest funktioniert, danke scorefun

Scorefun
23.01.2008, 15:04
das ist zunächst mal Text

als Zahl :

ZLong(Format([Datum];"jjjjmmtt"))

Josef P.
23.01.2008, 15:05
@Jahush: Was verstehst du unter einem DSum-Kritierium bzw. was hast du mit dem berechneten Feld vor?

Jahush
23.01.2008, 15:24
ich möchte eine lange liste von wöchentlcih autfretenden geldern kumulieren. vorher habe ich das immer so gemacht:
DomSumme("plankosten";"tbl_LC";"[Mathematisches Datum]<=" & [Mathematisches Datum] & "")
wobei das mathematische datum eine zahlt ist die folgendermassen aufgebaut ist: "Jahr" "monat" "kw" als beispiel 20080104
nur leider ist mir aufgefallen das es zb jetzt bei der jahreswende problmee damit gab. so wurde der 31.12.2007 unter 20071201 gelistet, weil er im kallender halt schin kw 1 ist. was die sortierung kaputt machte. die sah dann folgendermaßen aus (in kw)
die kallendeerwochen des dezembers
20071201
20071248
20071249
20071250
20071251
20071252
was ja ganz offensichtlich falsch ist. des diese eine kw 1 die leider im dezember liegt muss ganz unten am jahresende stehen.

daher hab ich danach meine dsum funktion versucht anders zu sortieren und hab das anstatt mit dem mathematischen datum mit einer monday of the week funktion versucht. die liefert wir aber nur eine spalte ohne inhalt. sprich keine fehlermeldung sonderne infach leere einträge.

nun wollte ich es mit einem mathematischen datum in der form 20071231 probieren. diesmal liefert access mir in der betreffenden spalte eine #Fehler meldung. weis grad ncith so recht was ich nun machen soll.

Josef P.
23.01.2008, 15:41
was ja ganz offensichtlich falsch ist. des diese eine kw 1 die leider im dezember liegt muss ganz unten am jahresende stehen.
eher, am Jahresanfang des nächsten Jahres, sonst wäre es KW53 und nicht KW01.

Bei Datepart() bitte auch die 2 optionalen Parameter der Funktion beachten.
bezüglich KW ... ein Blick in die FAQ 2.25 (http://www.donkarl.com?FAQ2.25) kann nicht schaden.

bTW: mich bringt eine Zahl die sich aus Jahr, Monat und KW zusammensetzt zum Nachdenken. Denn zw. Monat und KW gibt es keinen eindeutigen Zusammenhang.
Diese Varianten würde ich eher bevorzugen:
Jahr + KW ... Year(date()) * 100 + datepart("ww",date(),vbMonday,vbFirstFourDays)
Jahr + Monat + Tag ... format(date(), "yyyymmdd")
Jahr + Tag des Jahres ... Year(date()) * 1000 + datepart("y",date())

Andererseits verwende ich am liebsten einfach einen Datumswert, damit kann ich später machen was ich will.

Jahush
23.01.2008, 15:54
ich verstehe dann aber nciht warum meine dsum anweisung mit mo_of_week nciht tat. der jeweilige montag einer woche ist doch auch ein datumswert. weil es nciht eindeutig und mehrfach vorkommen kann? is das der fehlerverursacher der domsumme? also muss ich dafür ein eindeutiges feld nutzen oder wie.

Josef P.
23.01.2008, 16:00
ähm ... wenn in der Tabelle Zahlen stehen, die keinen direkten Datumsbezug mehr haben, wie willst du dann danach mit einem Datumswert filtern?
Beachte: msgbox clng(Date()) => liefert für den 23.01.2008: 39470

Vermutlich verstehe ich dein Vorhaben nicht. Kannst du eine Beispiel-mdb zur Verfügung stellen?

Jahush
25.01.2008, 13:17
hier die beispiel datenbank. dort sieht man die falsche sortierung bei dem jahreswechsel. ich brauch halt eine andere variable zum sortieren der tabelle. hätte da an mo_of_week gedacht, nur irgendwie funzt das nciht. vlt hilft dir das mien problem zu verstehen.

Josef P.
25.01.2008, 13:30
Also ich seh nichts. Die Abfrage sortiert so wie eingestellt korrekt nach dem Datum (nachdem ich den Fehler behaob, der beim Ausführen kam).
Du willst ein spezielles Feld zum Sortieren, hast aber z.b. in der Abfrage das Jahr, das Monat, die Kalenderwoche und ein Datumsfeld verfügbar.

Kann es sein, dass du die mit der Abfrage neu erstellte Tabelle ohne Sortierung als Datenbasis verwendest?

Jahush
25.01.2008, 13:49
die sortierung ist korrekt, aber shcua dir mal die kumulierten werte an. die verlaufen so (zb für den Planumsatz):
kw 48 nov 51,1k
kw 48 dec 51,5k
kw 49 dec 53,4k
kw 50 dec 55,3k
kw 51 dec 57,2k
kw 52 dec 59,0k
kw 01 dec 51,5k
kw 01 jan 60,6k

du siehst? ich habe meine dsum formel noch durch das mathematische datum berechnen lassen, das stimmte jedoch nciht. mein neues sortierkriterium ist ja mo_of_week.

Josef P.
25.01.2008, 14:07
Dann ist vermutlich die Berechnung der kumulierten Werte falsch.
Dass dein "matematische Datum" (Anm. für Mitleser: Zahl im Format: JJJJMMKW - aber KW und JJJJ unabhängig) nicht geeignet ist, stellen wir bereit fest, oder?
Und warum verwendest du es dann für DSum?

Bitte korrigiere einmal deine Test-mdb - die Abfrage konnte nicht einmal ohne vorherige Korrektur ausgeführt werden. (Statt Tabellenerstellungsabfrage würde zum Test auch eine "normale" Auswahlabfrage reichen.)


/edit:
Kann es sein, dass du dieses "matematische Datum" nur eingeführt hast, weil du nicht wusstest, wie man 2 Felder (z.B. Jahr + KW) kombiniert, um daraus eine kumulierte Summe zu gestalten?

Jahush
25.01.2008, 14:20
ich hab die test db einwenig beschränkt. der Planumsatz (ganz rechts) reicht ums zu sehen. und der Planumsatz ist auch der woher ich die werte hab die ich in meinem post drüber geschrieben habe.
ich hab diese abfrage schon seid längerm fertig. und erst zu dem jahreswechsel fiel mir auf das es da fehler gibt. vorher tat das mathematische datum soweit. deswegen ist es da ncoh drin. ich versuche ja nun meine dsum anweisung zu korigieren das es nun tut komme aber auf keine funktioniernede lösung. wenn ich als kriterium in meiner dsum anweisung das mathematische datum mit mo_of_week ersetze erhalte ich bei der ausgabe nur #Fehler
daruafhin kam mir ja der verdacht das ich also keine datumsfehlder nehmen kann für das suchkriterium.

/e
ich hab das datum eingeführt weil ich dachte es seih das ideale sortierkriterium.

Josef P.
25.01.2008, 14:36
Bei paar Möglichkeiten: (ob die Feldwahl richtig ist, weiß ich nicht. Bei der Vielzahl an redundanten Auswahlmöglichkeiten fällt es mir schwer dies zu beurteilen. ;))

Planumsatz: DomSumme("sum_plan";"lc";"[erster]<=" & ZLong([mo_of_week]))

Planumsatz: DomSumme("sum_plan";"lc";"[Jahr]<=" & [lc].[Jahr] & " AND [kw]<=" & [lc].[kw])
diese Variante mit Jahr und KW stimmt nur, wenn KW und Jahr auch zum Datum passen. (bei 31.12.2007 nicht Jahr 2007 und KW 1 sondern Jahr 2008 und KW1)

Jahush
25.01.2008, 14:53
Planumsatz: DomSumme("sum_plan";"lc";"[erster]<=" & ZLong([mo_of_week]))
sieht komsich aus. ich hab mal nenscreenshoot gemacht
in kw 22 (mai) ist da ein betrag von 1500 und in kw 22 (juni) 400. die kumulierte summe ist jedoch in beiden fällen 1500. erst für kw 23 steht dann da als kumulierter wert 3700, der single betrag für die woche war 1800 (1800+1500+400 = 3700)

kann ich also die monate aus meiner ansicht ganz löschen udn damit hab icha uch umgangen das zb die kw 22 2 mal auftaucht und der kumulierte betrag stimmt trotzdem? is ja super. danke =)

Jahush
25.01.2008, 14:59
ich hab die datenbank soweit überabeitet.
für kw 22 steht bei mir jedoch nur der kumulierte betrag von 1500. diese 390 die da ncoh weiter sind die werden erst in kw 23 draufgerechnet. zusätzlich zu den 1800 die da auch entstehen. (hab alles soweit summiert und gruppiert. hoffe es sieht nciht nur wegen denen so aus^^)
aber richtig wäre ja eigenlcih 1800 für kw 22 udn 1800 für kw 23

Josef P.
25.01.2008, 15:01
Nur noch einmal zur Wiederholung:
Jahr, Monat und KW machen nur in einer 2er-Kombination Sinn, aber nicht in einer 3er-Kombination.
+) Jahr + Monat
+) Jahr + Kalenderwoche (wobei hier aber das Jahr für die KW nicht das Jahr für jeden Tag aus dieser Woche sein muss ... siehe Beispiel 31.12.2007)

-) Jahr + Monat + KW => führt in deiner Abfrage zu doppelter Anzeige, weil eine KW 2 Monate betreffen kann und weiters die Tage einer KW nicht im selben Jahr sein müssen.

Ich weiß nicht, wie ich es besser beschreiben soll. Du musst dich einfach einmal etwas näher mit Datums-Berechnungen beschäftigen, dann wirst du bestimmt erkennen, was das Problem war.

zu #17:
verglichen wird der Montag der KW. Damit sind die Beträge vom Dienstag in der nächsten Woche. Ist das die Usache für die "Abweichung"?
Planumsatz: DomSumme("sum_plan";"lc";"[letzter]<=" & ZLong([mo_of_week])+6)

Was beschreiben "erster" und "letzter" eigentlich? ... ich dachte anfangs erster = Montag und letzer = Sonntag einer Woche. Dem ist aber nicht so.

Jahush
25.01.2008, 15:46
hmm...in meiner test db tat es. nun hab ich das feld in meiner abffrage umgeschrieben, und der wert fängt sobald ein jahreswechsel da ist bei 0 an neu hochzukumulieren :(

angehanegen einen screenshoot

Josef P.
25.01.2008, 15:57
Dann wirst du vermutlich etwas falsch umgeschrieben haben.