Office: (Office 2010) Jahrestabelle automatisch erstellen

Hi,
ich habe eine Tabelle die beinhaltet pro Datensatz die Felder JahrZ (Jahreszahl = 2014), Monatszahl (1…12) und Monatbez (Monatsbezeichnung = Januar…) sowie noch weitere Felder die später manuell monatlich befüllt werden. Ich würde jetzt gerne per Schaltflächenklick in einem Formular für das nächste Jahr 2015 zwölf neue Zeilen mit entsprechender Vorbefüllung für Jahreszahl, Monatszahl und Monatsbezeichnung anfügen. Da dies jedes Jahr immer wieder anfällt, würde ich dies gerne automatisieren. Ein Kombifeld womit ich das Jahr auswählen könnte habe ich schon ins Formular eingefügt. Weiß jemand wie man den Rest weiter umsetzen kann?

:)

 

Im Prinzip so (bei Buttonklick o.ä.):
Code:

Feldnamen, Datentypen etc. entsprechend anpassen.

Es genügt aber vollkommen, statt der drei Felder einfach in einem Feld ein Datum zu speichern, z.B. immer den Ersten des Monats.
Alles andere (Jahr, Monat, Monatsbezeichnung, ...) kannst du daraus leicht erzeugen.

maike

 

Hallo,

wo kommt denn der Inhalt (das Jahr) her, das das Kombi anzeigt ?

Die Tabelle gibt es schon (wird also verlängert), oder wird die für jedes Jahr neu erstellt ?


Solche Aktionen verleiten dazu das Datenmodell in Frage zu stellen.

was kommt denn in die weiteren Felder, bzw. was sind das für Felder?

 

Servus,
für mich sind das 3 in Beziehung stehende Tabellen
tbl_Jahr
tbl_Monat
tbl_Monatstag
und dann pro Monatstag weitere Aktionstabellen.

 

Hallo,
@Ohrkester
Wieso siehst Du das so?
In die Tabelle mit dem Monat müsste ja dann ein Fremdschlüssel zum Jahr, da kann ich auch gleich das Jahr nehmen, ist auch nur eine Zahl.
Und der Monatstag ist ja gar nicht gewünscht. Ob das Jahr redundant ist oder die Schlüsselzahl ist in dem Fall egal.
Bzw. Ich könnte das Jahr direkt als Fremdschlüsselfeld verwenden, dann kann ich aber auf die Jahrestabelle auch verzichten.

Aber prinzipiell halte ich das Datenmodell auch für zweifelhaft, hatte ich oben auch schon angezweifelt.

 

\@gpswanderer:

Da vermute ich noch weitere Unterteilungen wie z.B. Monatstage oder sogar Kalenderwochen und darin vorkommende Aktionen.

So wie ich es gelernt habe, sollten Schlüsselfelder möglichst keine echten Daten enthalten, sondern nur die Beziehungen der Tabellen zueinander.
Schlüsselfelder sollen nach der Entwicklung der DB in Formularen/Berichten unsichtbar werden. Wenn da reale Daten drin sind, geht das nicht mehr.

 

Hallo,
ich sehe da absolut keinen Sinn, für das Jahr eine extra Tabelle anzulegen.
In dem Fall bleibt das Schlüsselfeld (=Jahr) halt sichtbar.

das ist keine feste Regel.
Ein Autowert als Rechnungsnummer z.B. muss auch sichtbar bleiben.
Es spricht auch nichts gegen einen Autowert als Rechnungsnummer.

 

\@gpsWanderer:

Dazu gabs noch keinen Kommentar von Dir.

Es spricht 1. dagegen, weil ich NIEMALS Datenfelder mit realen Daten als
Schlüsselfelder verwende; auch wenn Access und viele Anwender anderer Meinung sind und es vielfältig anderweitig benutzen.
Deren Gejammere bei unsauberer DB-Modellierung ist doch bekannt.

Es spricht 2. dagegen, dass das Finanzamt keine Lücken in Rechnungsnummern akzeptiert.

Prinzipiendiskussionen lass ich hier besser.
Sie verwirren uns und den Fragensteller.

 

Hallo,

Du schreibst ja selbst "möglichst". Wenn das Feld eine Zahl ist und somit als Schlüsselfeld taugt spricht da absolut nichts dagegen. In einer Artikeldatenbank, bei der man mit der Artikelnummer frei ist kann man völlig problemlos ein Autowert dazu verwenden. Wozu dann noch mal extra einen Primärschlüssel. Daran ist nicht das geringste unsauber und das Datenmodell stimmt auch.

das ist ein weit verbreiteter Irrtum, das ist seit 6 (!) Jahren überholt. Eine Rechnungsnummer muss eindeutig sein, sonst nichts.

Aber Du hast recht, das ist jetzt OT.

 

Hi Maike,
ich habe deinen Vorschlag auf meine Belange wie folgt umgesetzt:
Code:

Die Felder sind in der Reihenfolge angelegt als Zahl, Zahl und Text.
Leider erhalte ich den Laufzeitfehler 3134, Syntaxfehler in der INSERT INTO-Anweisung.
Was ist hier noch nicht richtig?

 

Hallo,
versuche es mal so:

Code:

Im Formular sollte ein Feld sein, mit dem Namen "gewJahr" in das man das gewünschte Jahr einträgt.

Der Monatsname ist überflüssig, den erhältst Du mit der Funktion
Code:

über eine Abfrage.

Leider hast Du Dich zum Tabellenaufbau nicht weiter geäußert, normalerweise sollte das in dieser Form in einer DB nicht notwendig sein.

Nachtrag:
Nenne das Kombi mit der Jahreszahl "gewJahr".
Was sind das für Zusatzinformationen die in der Tabelle gespeichert werden?

 

Hi Klaus,
die Jahreszahl stammt aus einer Tabelle wo nur Jahreszahlen drin stehen. Die Tabelle wo die Datensätze angefügt werden sollen gibt es schon. Die anderen Felder sind Textfelder wo Zusatzinformationen erfasst werden.

 

\@gpswanderer:
Nun möchte ich eigentlich nur noch meine Verwunderung äussern, da
Du heute eine Haltung einnimmst, welche durchaus einer berechtigten Silvesterstimmung entspricht, leider aber keine Fragen meinerseits beantwortet.
Ich schliesse diesen Thread meinerseits mit dem nochmaligen Hinweis an den Threadstarter: "Ich wünsche ein gutes neues Jahr und weiterhin viel
Glück"

 

Hallo,
allen zusammen ein gutes Neues Jahr.
@Ohrkester
Ich verstehe nicht ganz, warum Du hier so eingeschnappt reagierst. Das war doch bisher eine ganz sachliche Diskussion. Wir tauschen doch nur Meinungen aus.
Ich bin doch nicht Dein Gegner. Und wo hast Du Fragen versteckt, ich konnte jedenfalls keine erkennen.

Zurück zum OT Thema *grins
Die von Dir angesprochenen Regeln, sind Regeln die sich aus Foren entwickelt haben, das meiste davon wende ich auch an. Es sind aber keine Datenbankregeln. Ein Primärschlüssel muss eindeutig sein, sonst nichts. Wenn er dann noch eine Zahl ist, so ist das vorteilhaft, aber nicht zwingend. Und wenn der Primärschlüssel sprechend ist, dann ist das auch OK. Dass ich den nicht ausblenden kann ist dann auch klar. Und wenn eine Personalnummer als Zahl vorhanden ist, warum soll ich dann extra einen Autowert als PS einfügen?
Das Datenmodell ist auch mit der Pnr als PS völlig korrekt.
Und das Jahr als einzelnes Feld als Tabelle anzulegen, nur um es dann als Fremdschlüssel wieder verwenden zu können macht doch wirklich keinen Sinn.

Von Andreas Kelz gibt es ein Dokument "Relationale Datenbanken". Dieses Dokument ist eine sehr häufig verwendete Dokumentation zum Thema. Ist auch bei vielen Usern hier im Forum als Link in der Signatur zu finden.

Und hier:
http://v.hdm-stuttgart.de/~riekert/l...kelz/index.htm
Beachte Kapitel 4 Normalisierung.

In dieser Erläuterung findest Du nur sprechende Primärschlüssel (Rechnungsnummer, Kostenart, Personalnummer, PLZ).
Es werden auch zusammengesetzte PS verwenden, die in den Foren auch verpönt sind und trotzdem den Regeln entsprechen. Viele Profis sagen auch diese wären vorzuziehen. Was ich persönlich nicht tue. Aber ich gehöre auch nicht zu den wirklichen Profis. Ich mache das immer noch ausschließlich als Hobby.
Das Dokument enthält auch ein negatives Beispiel, die PLZ. Diese taugt nicht als PS, da die PLZ nicht eindeutig ist. Hier müsste man einen Autowert einbauen oder einen zusammengesetzten PS (PLZ und Ort) verwenden.

@jobee
Wozu eine Tabelle die nur die Jahreszahlen enthält ?
Und erkläre bitte mal was das für weitere Felder sind in der Tabelle in der Jahr und Monat angefügt werden. Ich denke, hier gibt es noch Optimierungsbedarf.

 

Man könnte auch die Überlegung anstellen, dass, wenn pro Jahr zwölf Datensätze reichen, der Optimierungsaufwand (so gering er sein mag) den möglichen Nutzen weit übersteigen kann. Nicht an jedes Gebilde muss man die Anforderungen einer Datenbank stellen.

Falls es sich um eine Datenbanklösung handeln sollte, würde ich maikes Vorschlag aus #2 aufgreifen und nur den jeweils Monatsersten als Datum verwenden und speichern. Formate wie Jahr, Monatsname, Kalenderwoche und viele andere mehr kann man per Berechnung von einem Datum ableiten oder - wenn es dann eine Datenbank mit Datenmengen betrifft - aus einer Kalendertabelle per Nachschlagen entnehmen.

Ein Datum würde auch die Variabilität erhöhen. So wären z.B. beliebige Zeitraumauswertungen erst möglich, so auch jahresübergreifende. Mit einem Datum kann man rechnen, z.B. 17 Monate zurückblicken.
Variabilität und Skalierbarkeit sind Elemente einer richtigen Datenbanklösung.

Zusätzlich müsste man das Bereitstellen von Dummydatensätzen in Stammdatentabellen bemängeln. Datensätze legt man in Stammdaten besser dann an, wenn man Werte (vollständige Datensätze) vorliegen hat. Für Dummies und deren Bereithaltung bemüht man (durchdachte) Hilfstabellen wie eben eine Kalendertabelle. Im Anhang eine einfache Demo dazu.