berechnete Spalten können nicht in Systembeziehungen verwendet werden

Danke!
Das mit der Ereignisprozedur funktioniert.
Ich habe inzwischen Formulare angelegt mit denen ich neue Sportarten (frm_EingabeneueSportart) und neue Aktivitäten (frm_EingabeneueAktivität) eingeben kann.
Zusätzlich habe die Datenbank noch weiter normalisiert, in dem ich eine weitere Tabelle T-Rundkurs (ja/nein) angelegt und verknüpft habe.

Wo ich jetzt noch hänge ist Folgendes:
Jetzt ist die Tabelle T_Region mit der Tabelle T-Sportart und die Tabelle T_Land mit der Tabelle T_Region verknüpft.
Wenn ich nun eine neue Sportart anlegen will, gelingt es mir zwar im Formular frm_EingabeneueSportart eine Region auszuwählen (zB Nord), aber ich schaffe es nicht über in Kombinationsfeld o.ä. im Formular auch die Möglichkeit zu bekommen, das richtige Land dazu auszuwählen (die Region Nord gibt es ja in Albanien und in Kroatien).

Grüße
Markus
 

Anhänge

Werbung:
Zuerstmal: Warum hast Du das Formular frmT_Land gelöscht? Das Unterformular UfmT_Region steht nun elternlos da. :-/

Zur Fragestellung: Kombinationsfelder haben eine eigene Datenherkunft. Soll heißen, lege eine Abfrage an, die dir die Regionen inklusive der Länder anzeigt. Die kannst Du dann als Datenquelle für das Kombinationsfeld nutzen. Achte dabei darauf, das die gebundene Spalte die ID Nr des Datensatzes mit der richtigen Kombination aus Land/Region ist und in die Tabelle Sportarten eingetragen wird.
 
ok, zuviel gelöscht, Formular frmT_Land gibt es wieder,

Die Eingabe neuer Sportarten mittels Formular "frm_EingabeneueSportart" funktioniert nun, so dass ich bestehende Länder/Regionen auswählen kann.

Nach dem gleichen Schema wollte ich nun ein Formular "frm_EingabeneueRegion" für die Eingabe neuer Regionen bzw. neuer Länder machen.
Datensatzherkunft des Formulars wäre die Abfrage "q_Land_Regionen", aber egal wie ich das Kombinationsfeld designe (basierend auf die Abfrage oder auf die Tabellen T-Land oder T-Region) es gelingt mir nicht die Eingabe von Region und Land zu ermöglichen.
Irgendwie stehe ich vermutlich auf der Leitung.

Grüße
Markus
 

Anhänge

Die Eingabe von Ländern und Regionen erfolgt doch über das Formular fmT_Land. Warum willst Du den da noch ein Formular für die Regionen machen? Macht doch keinen Sinn. Im Hauptformular wird doch das Land aufgerufen oder eingegeben. Daraufhin erscheinen automatisch, synchronisiert die Regionen des gewählten Landes. Also zuerst im Hauptformular ein neues Land anlegen und dann im UF die Regionen eintragen. Durch die Beziehungenist das automatisch richtig. Wenn Du nur zu einem bereits vorhandenen Land eine neue Region anlegen möchtest geschieht dies so: Zuerst Land aufrufen und dann im UF die Region zufügen.
 
OK, verstehe, ich wollte das ohne Unterformular lösen.

Mit diesen Formularen könnte ich aber jetzt ein Land doppelt anlegen. Gibt es eine einfache Lösung dies zu verhindern?

Und jetzt noch die entscheidende Frage:
Wie kann ich jetzt in diese DB-Struktur mit den Testdaten meine Echtdaten hineinbringen?

Grüße Markus
 
Du kannst in der Tabelle das Textfeld Land auf indiziert ohne Duplikate setzen. Das funktioniert aber nur, wenn Du vorher deine Daten bereinigst. Soll heißen, Du musst die die Tabelle zuerst so pflegen, dass es jedes Land nur einmal gibt. Dabei müssen natürlich die Regionen, die bei den Dubletten hinterlegt sind, auch zu dem übrigbleibenden Land zugeordnet werden, damit die Daten den Regeln entsprechen.

Da die Ursprungsdaten kaum normalisiert sind, ist es nötig genau die Struktur zu beachten. Ich weiss nicht wie umfangreich deine Echtdaten sind. So ist die Frage: Lohnt es sich Übernahmeprozeduren und Abfragen zu bauen, weil eine händische Übernahme aufgrund der schieren Menge inakzeptabel ist? Oder ist es vielleicht schneller gemacht per Copy/Paste Zeilen und Felder zu übertragen. Dabei wirst Du nicht umhin kommen Schlüssel und Fremdschlüssel im Auge zu haben.
Eine gute Methode ist es die Daten in Exceltabellen, die genau die gleichen Spalten enthalten vorzubereiten. Ohne ID-Spalten, weil die werden ja später automatisch bei der Übernahme erzeugt. Also zuerst eine Haupttabelle, zB. Länder erzeugen und in Access über die Importfunktion einlesen und dann mit einer Anfügeabfrage in die Landtabelle der DB bringen. Dann die Regionentabelle aufbauen und die Fremdschlüssel, die man ja nun der echten Land-Tabelle entnehmen kann, nachpflegen. Dann kann die Regionentabelle importiert werden. Ähnlich dann die anderen Tabellen vorbereiten. Wichtig, die Schlüssel und Fremdschlüssel müssen passen. Ansonsten verweigert Access die Anlage der Datensätze und erzeugt nur Tabellen mit Name Einfügefehler.
 
Danke
Meine Sportdatenbank enthält 3861 Aktivitäten und 832 Sportarten !!
Habe ich zuerst lange in Excel geführt und dann nach Access transferiert und hier dann ein paar Jahre nur mit Tabellen, Berichten und Abfragen gearbeitet.
Ich werde mal mit Excel-Exports/Imports probieren und dann mittels Anfügeabfrage einlesen.

Grüße Markus
 
Ich hätte jetzt noch folgende Frage

Auswertemöglichkeiten des Datums (nach Monat, Kalenderjahr, Quartal) sind ja als Standard bei Erstellung von Diagrammen bereits vorhanden.

Ich benötige ausgehend vom Datum der Aktivität aber noch folgende Auswertemöglichkeiten:

a) Saison
Zuordnung des Datums zu einer Saison,
zB soll alle Aktivitäten vom 1.7.2023 bis 30.6.2024 der Saison 2023/2024, der 1.7.2024 bis 30.6.2025 aber der Saison 2024/2025 zugeordnet werden können.
Damit kann ich dann alle Winteraktivitäten (Schifahren, Schitouren) über eine Wintersaison auswerten und nicht nur pro Kalenderjahr.

b) Jahreszeiten
Zuordnung des Datums zu einer Jahreszeit.
ZB sollen alle Aktivitäten vom 1.12.2024 bis 28.2.2025 dem "Winter24/25" zugeordnet werden und alle Aktivitäten 1.3.2024 bis 31.5.2025 dem "Frühling25"

Mache ich das am Besten mit spezieller SQL-Programmierung oder besser mittels VBA.

Grüße Markus
 
Hallo Markus,

eine Möglichkeit und das wäre wahrscheinlich die einfachste, Du legst Dir eine Kalendertabelle an, in der Du jedem Tag seine Kriterien zuordnen kannst. Das Datumsfeld bildet den Index. Weitere Felder wären, in diesem Fall Saison, Jahreszeit, aber auch Feiertag oder auch Wochentag. Obwohl für Wochentag gibt es ja auch schon eine Standardfunktion.
Die Tabelle läßt sich mit Excel schnell erstellen und nach Access importieren.
So schaust Du bei einer Abfrage mit dem jeweiligen Datum einfach in die Tabelle und weißt, was in den anderen Feldern für den jeweiligen Tag steht.
Wenn Du dann noch Funktionen baust. Saison(D) und Jahreszeit(D), wobei D als Datumsparameter zu sehen ist, den Du jeweils mitgibst, kannst Du die Funktionen einfach überall anwenden, auch in Abfragen. Die Funktionen müssen nur in einem allgemeinen VBA-Modul als Public Function liegen. Dann einfach mit Dlookup das Datum ermitteln.

Wenn Du keine Kalendertabelle möchtest kannst Du natürlich auch in den Funktionen das Ergebnis mit VBA ermitteln.
Das ist eine schöne Übung um mit Datumsfunktionen wie DatSerial, Datadd usw. umzugehen. Man achte dabei auf die vielen Datumsformate, die es gibt und wie Access sie verarbeitet. Intern ist ist das ja nur eine Long Integer Zahl. Aber angegeben wird es mit der amerikanischen Schreibweise #mm/dd/yyyy#. Und es gibt auch einige Umrechnungsfunktionen, die es sich lohnt auch mal anzuschauen. (CDate, usw.)

Du solltest auch noch wissen, dass man ein Datum auch in seinen Teilen ansprechen kann: Day(MeinDatum), Month(MeinDatum) oder Year(MeinDatum). In Abfragen auf Deutsch: Tag(Meindatum), usw.

Datums- und Zeitberechnungen sind ein weites Feld.
 
Mit Excel hatte ich das bisher schon versucht. Das hat aber den Nachteil, dass auch in Excel manuell oder mit viel Formeln die passenden Berechnungen (zB für Jahreszeit Winter23/24 die Monate Dez24, Jän25 und Feb25 zusammenfassen) durchgeführt werden müssen.

So eine Tabelle sieht ja dann zB so aus

JahrMonat Jahreszeit JahreszeitJahr Saison .....
202306 Sommer Sommer23 Saison22/23
....
202307 Sommer Sommer23 Saison23/24
.....
202312 Winter Winter23/24 Saison23/24
202401 Winter Winter23/24 Saison23/24
202402 Winter Winter23/24 Saison23/24
202403 Frühling Frühling24 Saison23/24

Und bekomme ich dann nicht in Access ein Problem mit der Verknüpfung von Tabellen, wenn die "Kalendertabelle" bereits Datensätze bis zB Dezember 2026 enthält, die Tagebuch-Tabelle Einträge aber nur bis März 2025 enthält?

Und was passiert, wenn ich die Kalendertabelle auf Tagesbasis aufbaue, in der Tagebuch-Tabelle ja nicht alle Tage vorkommen? Oder ich die Kalendertabelle auf Monatsbasis ich aber in einem Monat keine Aktivitäten habe?

Was mir noch nicht klar ist betreffend VBA:
Ich habe bisher bei Abfragen mittels SQL diverse Datumseinschränken gemacht, zB WHERE (((Tagebuch.Datum)>#12/31/2019#))
Wenn ich jetzt wie du vorschlägst sowas mittels VBA machen soll, wie starte ich dann eigentlich den "VBA-Generator.
Einfach in der Abfrage den VisualBasic-Button, dann eine neues Module eingeben und dann

Public Sub Datumsberechnung()
irgendeine Datumsberechnung
End Sub

Oder bin ich da komplette falsch unterwegs?

Grüße
Markus
 
Moin,
ich glaube Du machst Dir gerade das Leben selbst kompliziert. Natürlich muss die Kalendertabelle auf Datumsebene geführt werden, damit zu jedem beliebigen Tag die passenden Ergebisse ermittelt werden können. Die Spalten Monat und Jahr kannst Du dir schenken. Die hast Du ja immer als Standardfunktion verfügbar. (Siehe oben Day(Meindatum), etc.). Die Saison und die Jahreszeit kannst Du dann ja immer leicht aus der jeweiligen Datumszeile, besser gesagt, dem jeweiligen Datensatz, ermitteln. (s.o DLookUp).
Ein Beziehung zwischen der Kalendertabelle und anderen Tabellen ist dann eher eine 1:1-Beziehung. Es sei denn in der anderen Tabelle kann dasselbe Datum mehrmals vorkommen. Ob man überhaubt eine Beziehung benötigt muss die Anwendung zeigen.

Die Tabelle in Excel zu bauen hatte ich nur vorgeschlagen, weil Excel sehr komfortabel ist, was die Erstellung von (Datums)Spalten ist. (Runterziehen um die Tabelle zu füllen schreibt das Datum in der Spalte im vorgegebenen Format fort.) Nix Formeln oder so.

Wenn Du eine Datumsberechnung in VBA durchführen möchtest, ist das ohne zumindest grundlegende Kenntnisse in VBA nicht zu machen.
(Und ebenso Kenntnisse wie man VBA bedient...)
Dazu empfehle ich Visual Basic für Applikationen - Das VBA-Tutorial mal zu lesen.

Und warum quälst Du dich mit SQL? und nutzt nicht die Q(uery) b(y) E(xample) des Abfrageassistenten? Wenn dich das SQL-Statement interessiert kannst Du es dir dann ja einfach ansehen. (Unten rechts Ansicht auf SQL umstellen).
 
Hallo

Nochmals zur Excel-Kalendertabelle
Dass ich die täglichen Datumswerte im Excel einfach durch runterziehen fortlaufend kopieren kann, ist mir klar. Und natürlich kann ich Monat, Jahr, Wochentag leicht berechnen
Um aber ein bestimmtes Datum meinen Auswertewünschen zuordnen zu können, also zB
  • den 30.6.2023 der Saison_2022/2023 und
  • den 1.7.2023 der Saison 2023/2024
zuzuordnen oder
alle Datumseinträge Zb
  • vom 1.12.2022 bis 28.2. 2023 dem Winter_2022/2023
  • vom 1.12.2023 bis 28.2. 2024 dem Winter_2023/2024
zuzuordnen, muss ich in Excel entweder
  • mit ziemlich viel verschachtelten WENN(...) arbeiten oder
  • auch in Excel mit VBA arbeiten oder
  • dies händisch machen (*)
*) das ist machbar, aber aufwändig denn ich habe Datensätze seit Ende 1999

Und erst dann kann ich die Tabelle in Access einlesen und dann darauf Abfragen aufbauen.
Oder reden wir da jetzt aneinander vorbei?

Was meinst du oben mit " Wenn Du dann noch Funktionen baust. Saison(D) und Jahreszeit(D)" ? Funktionen in VBA ?

Grüße
Markus
 
Hallo Markus,

ist der Anfang und das Ende einer Saison in jedem Jahr an den gleichen Datümern? Wenn ja, wie definierst Du Anfangs-und Endedatum für dich?
Und, ist es mit mit der Jahreszeit auch so? Dann nenne auch da mal Anfangs und Endedatum.
 
HI

Also die Logik geht so:
Ich beziehe mich bez. Jahreszeiten auf die meteorologischen Jahreszeiten und daher die "Stichtage" 1.3., 1.6., 1.9., und 1.12. und betreffend der Saison ist der 1.7. der Stichtag

1.6.2022 bis 30.6.2022 Sommer2022Saison_2021/2022
1.7.2022 bis 31.8.2022Sommer2022Saison_2022/2023
1.9.2022 bis 30.11.2022Herbst2022Saison_2022/2023
1.12.2022 bis 28.2.2023 Winter2022/2023 Saison_2022/2023
1.3.2023 bis 31.5.2023 Frühling2023Saison_2022/2023
1.6.2023 bis 30.6.2023 Sommer2023Saison_2022/2023
1.7.2023 bis 31.8.2023Sommer2023Saison_2023/2024
1.9.2023 bis 30.11.2023 Herbst2023Saison_2023/2024
1.12.2023 bis 28.2.2024Winter2023/2024 Saison_2023/2024
1.3.2024 bis 31.5.2024 Frühling2024Saison_2023/2024
1.6.2024 bis 30.6.2024Sommer2024Saison_2023/2024
1.7.2024 bis 31.8.2024Sommer2024Saison_2024/2025

Zur Info
Ich benötige diese Aufteilung auch für meinen 2. Datenbank (Auswertung der Energieverbräuche zB nach Heiz-Saison), deshalb möchte ich das natürlich so automatisiert wie möglich machen

Grüße Markus
 
Werbung:

Ähnliche Themen

W
Tabellen für "Wettkampfdatenbank" (Anfängerfrage)
Antworten
6
Aufrufe
6K
ukulele
ukulele
Zurück
Oben