Office: (Office 2010) Zeitzyklen berechnen, nur Werktage, oder mit oder ohne Feiertage

Hi,

danke, jaja, ich nutz die KnowHow noch Nun ja, die genannte Datei ist auch mehr oder weniger ein Ableger davon ...

mfg KLaus

 

Hallo Nouba,
ich danke Dir sehr.
Ich werde jetzt versuchen das mal zu nutzen.
Wenn ich es nicht hin bekomme melde ich mich noch mal.

Läßt sich die Tabelle "td" eigentlich weiter führen? Ich hatte die Anf-Abf mal angeschoben, holla da wirste ja abgefragt...

Was hat das eig. mit der Tabelle "t10" auf sich?
In der Vorgängerversion habe ich eine Tabelle gesucht "x" die hast Du jetzt nicht mehr mit drin.

Ich sage bescheid ob ich es hin bekommen habe.
Steht ja noch die Sache mit dem einlesen aus (der anderer Thread) , da muss ich auch erst mal sehen. War schon besser das ganze zu trennen.
Als dann. DANKE an Dich und alle die mit geholfen haben.

 

Nein Eberhard, kein Geheimnis.
Es ist ganz simpel.
Es gibt keinen Grund sich an die Regeln der Normalisierung zu halten, wenn man weiß was man tut.

Ich kann für den Feiertag einen Index einer Fremdtabelle oder eben wie in dem Beispiel den Namen einsetzen. Macht dann pro Zeile über die verschiedenen Texte mehrere Hundert Byte aus.
So einfach ist das. Beides hat Vorteile.

Da geht es nicht um eine Dissertation, oder eine unsinnige Diskussion, sondern nur um Hausverstand.

LG M

 

Hi Unklar,

die T10 wird nirgends verwendet.Eine Tabelle x gab es nie - nur einen Alias auf eine Abfrage namens x in der ersten Version.

Im Modul td_support gibt es die Prozedur PopulateDimensionTable, die eine Jahreszahl als Argument erwartet, um Datensätze für ein weiteres Jahr anzulegen. Diese Prozedur nutzt dann die Anfügeabfrage.

 

Hallo Nouba,
Danke für die Ausführungen.
Wozu nutzt man solche Alias? Wie legt man sie fest? Macht so etwas Sinn, naja denke schon sonst hättest Du es nicht rein gebracht.
Ich bin gespannt ob ich das heute zu mindest für die Datumsberechnung hin bekomme. Gebe mir Mühe. *biggrin.gif*

 

Hi Unklar,

im ersten Fall frage ich z.B. mit Code:

die ersten 15 Arbeitstage aufsteigend sortiert nach dem Datum ab. Ich will aber nur den letzten (also den 15. Datensatz) im Ergebnis haben. Also muss ich meine Abfrage erneut abfragen. Weil ich diese aber nicht abgespeichert habe (das Zwischenergebnis ist ja nicht von Interesse), setze ich eine weitere Abfrage auf die erste (innere) Abfrage ab, die ich dann absteigend sortiere. Code:

Damit SQL (nicht nur in Access) die Felder der inneren Abfrage handhaben kann, muss man diese benennen (der Name kann frei gewählt werden, sollte i.d.R aber kurz und prägnant sein) - ansonsten vergibt Access selbst ein sehr kryptischen Namen. Das kannst Du einfach einmal mit jeder beliebigen Tabelle ausprobieren - dann siehst Du, was Access dann einsetzt. Gib in der SQL-Ansicht einfach einmal soetwas ein, wobei der Tabellenname natürlich vorhanden sein muss. Code:

Bei eingeblendetem Eigenschaftsfenster und Klick auf die dargestellte innere Abfrage im Abfrageentwurf, siehst Du dann unter Alias den Namen, den Du jederzeit ändern kannst.

Ansonsten nutzt man auch Alias-Namen für Tabellen oder Abfragen, wenn deren Name lang ist - das verkürzt den Abfragetext (siehe SQL-Ansicht) oft enorm.

Eine andere, Dir vermutlich bekannte Form von Alias-Namen sind Feld-Aliase, die im Abfrageeditor in der Feldliste als Präfix mit folgendem Doppelpunkt vor einem Ausdruck verwendet wird. In SQL wird diese Form eines Alias dann genau umgekehrt, nämlich so: ... Ausdruck_oder_Feldname AS AliasName, ... dargestellt.

In einigen SQL-Dialekten ist das Schlüsselwort AS optional - in Access jedoch nur bei einem Tabellen-Alias.

 

Hallo Nouba,
ich muss noch mal fragen:
"Läßt sich die Tabelle "td" eigentlich weiter führen? Ich hatte die Anf-Abf mal angeschoben, holla da wirste ja abgefragt... "
"Im Modul td_support gibt es die Prozedur PopulateDimensionTable, die eine Jahreszahl als Argument erwartet, um Datensätze für ein weiteres Jahr anzulegen. Diese Prozedur nutzt dann die Anfügeabfrage."
Ich habe mal versucht das von Dir beschriebene unter ausführen Code anzuschieben, hat leider nicht geklappt, was mache ich falsch?
Leider hat man mich derzeit auch noch mit dem Thema SharePoint zugeschüttet und einer Truckbetankung unterzogen. *rolleyes.gif*
(Ich habe noch bis Do. dann habe ich für ne Wo. Urlaub und dümple mit einem Boot auf den Masurischen Seen herum.
Ein ausgeschaltetes Handy ist dann das einzige technische Equipment das ich bei mir habe.)

 

Ich habe gerade im Direkt-Fenster erfolgreich mit Code:

Tage für das Jahr 2020 angelegt. Wo ist das Problem?

 

Hier müsste man die an sich überflüssige Frage (bei einer hinreichend vollständigen Beschreibung) stelllen: WAS hast Du gemacht?

 

Hallo zusammen,
bin erst heute a.U. zurück, ich bin noch dran! Schraube erst mal und wenn es was gibt melde ich mich.

 

Hallo, ich bin zurück und will mich dem Thema nun weiter verstärkt widmen.
Ich habe nun noch einmal versucht ein neues Jahr in die Tabelle td zu bringen.
Lässt sich ein neues Jahr denn nur über das Direkt-Fenster generieren, oder kann ich dazu auch einen Codeaufruf "von aussen" durchführen?
Ich möchte ja nicht das jeder in dem Code herumpfuscht. (wenn nix mehr geht wahrs keiner, wie immer)

Im übrigen habe ich den Code wie Du schreibst im Direkt Fenster nicht zum laufen gebracht, wurde immer angemeckert.
Ich habe den Tipp bekommen über:

Sub TE()
PopulateDimensionTable 2020
End Sub

Den Aufruf zu machen.
Ist aber auch recht starr. denn auch da müsste ich in den Code gehen.

Ich bin leider nicht dahinter gestiegen, wie ich die einzelnen Abfragen die das entsprechende Datum zusammenstellen ansprechen kann.
Der Name der entsprechenden Abfr. steht in der Tabelle "ReportList" in der Spalte "Spalte Assoc_Queryin" (siehe Beispiel DB)
Darüber wird doch auch die entspr. Abf. aufgerufen, oder nicht?
Sonst wüsste ich nicht, wie ich aus meiner TblZyklus in der ich die Spalte Assoc_Query auch hinein gebracht habe die Abfr. aufrufen kann.

Die Datumsermittlung wird sich auch noch komplizieren, weil man nun der meinung ist, es kann ja mal sein das ein Bericht bis zu 5 Tage später erstellt werden darf. Toll, ich dachte ein Stichdatum, daraus ein Dateinamen (mit dem Datum) und gut.
Aber das soll später kommen, erst mal das normale Procedere. Ansonsten fällt denen noch weitere Schwachheiten ein.

 

Öffentliche(Public) Methoden in allgemeinen Modulen lassen sich außer in Tabellen von überallher aufrufen. Das ist Basis-Wissen, das man in 13 Jahren Umgang mit Access sich angeeignet haben sollte.

Die Spalte Assoc_Query ist dazu gedacht, den richtigen Algorhitmus für einen Report festzulegen - mit 7. Arbeitstag des Monats oder Donnerstags (oder danach) kann Access wenig anfangen.

 

Auch wenn ich es gerne anders hätte, ich bin mal zu dumm gewesen "hier" zu rufen. Mein Aufgabengebiet ist ganz ein anderes, deswegen festigt sich das ganze nur wenig.
Ansich hast Du aber recht. Ich danke Dir aber trotzdem, die Tipps waren immer klasse von dir auch wenn ich sie meist erst in 2. Anlauf verstanden habe.

Du schreibst "Die Spalte Assoc_Query ist dazu gedacht, den richtigen Algorhitmus für einen Report festzulegen"
So heißen doch aber die Abfragen auch, hat das nichts damit zu tun?

 

Ja,natürlich hat das was damit zu tun. Hier noch einmal der Code (etwas kommentiert) aus dem Beispiel-Formular: Code:

 

Hallo,
ich habe es leider trotz Deiner Kommentierung nicht hin bekommen.
Ich habe auch die Struktur abändern müssen. Denn es steht nun doch die Forderung, das ein Bericht mehrere Zyklen haben soll. OK, ist es wenigstens jetzt gekommen und nicht erst wenn alles so weit fertig ist. Es soll auch möglich sein jedem Bericht eine Karenz (Abweichung) zuzuordnen. (eigentlich am 1.4.2018 bis 5.4.2018 möglich) das heißt ja für mich das ich 6 Dateinamen einmal suchen muß.

Ich habe nun eine Abfrage dazu gebracht die das Fälligkeitsdatum aktualisieren soll. Die Abf. ist natürlich nicht gelaufen, ist im Moment auch nur eine Auswahlabfrage und keine Aktualisierungsabfrage.