berechnete Spalten können nicht in Systembeziehungen verwendet werden

[mareinki]

Hallo

Ich habe in Access schon einige Abfragen und Berichten erstellt, bin aber sicher kein Profi.
Hiermit meine Frage zu meiner Sport-Datenbank:

Ich habe folgenden Tabellen:

Tabelle Sportart mit Feldern

• ID
• Kategorie (ZB Schifahren, Badminton, ...)
• Streckenbezeichnung
• Höhenmeter
• Entfernung
• etc.

Tabelle Tagebuch mit Feldern

• ID
• Datum
• Zeit
• Puls
• JahrMonat (zB 202502 berechnet aus Datum)
• etc.

Bei Eingabe einer neuen Aktivität werden über den Nachschlagesassistent die passende Sportart aus Tabelle Sportart ausgewählt

Bisher habe ich für diverse Abfragen die Tabellen Tagebuch und Sportart wie folgt per SQL angesprochen (tlw mit Einschränkungen auf ein Jahr, oder Sporarten

SELECT Tagebuch.Datum, Tagebuch.Zeit, Tagebuch.Puls, Sportart.Kategorie, Sportart.Streckenbezeichnung, Sportart.Höhenmeter, Sportart.Entfernung, Format$(Tagebuch.Datum,'yyyymm') AS JahrMonat
FROM Sportart INNER JOIN Tagebuch ON Sportart.[ID] = Tagebuch.[Sportart_ID];
WHERE (((Tagebuch.Datum)>#12/31/2022# And (Tagebuch.Datum)<#1/1/2024#))

Manche Sportarten wie Schifahren, Skitouren sollen nun aber pro Wintersaison ausgewertet werden und nicht pro Kalenderjahr. Deshalb habe ich eine weitere Tabelle Saison erstellt

Tabelle Saison mit Feldern

• ID
• Monat
• Jahr
• JahrMonat (zB 202502)
• Wintersaison (zB 2024_2025_Wintersaison)

Das Feld Wintersaison hat folgende Logik: Die Monate 07 bis 12 2024 und 01 bis 06 2025 werden der "2024_2025_Wintersaison"zugeordnet.


Nun wollte ich die Tabelle Saison per SQL mit den Tabellen Sportart und Tagebuch verknüpfen um die Sportarten auch je Saison auswerten zu können

Wenn ich versuche die Tabellen Tagebuch und Saisonen über die Felder Tagebuch.JahrMonat und Saison.JahrMonat zu verknüpfen bekomme ich die Fehlermeldung:

"berechnete Spalten können nicht in Systembeziehungen verwendet werden".

Ich habe bewusst die Tabelle Saison angelegt und nicht die Felder bereits in der Tabelle Tagebuch berechnet, da das ja einem guten DB-Design widersprechen würde.

Kann mir jemand einen Tipp geben, wie ich das Problem lösten kann.

Grüße
Markus

 

[dabadepdu]

Kann mir jemand einen Tipp geben, wie ich das Problem lösten kann.

Alles recht ausführlich beschrieben, aber leider fehlt die Abfrage, die den Fehler auslöst und die Datentypen der Spalten.
Verwendest Du berechnete Spalten? Ich hab irgendwo gesehen, dass das erst ab '2010 geht, find ich aber grad nicht.

Wenn Du keine berechneten Spalten verwendest, ist es vielleicht einfach ein Tippfehler oder Syntaxfehler, der zu einer nicht plausiblen Fehlermeldung führt.
Wenn doch, müsste es ja mit der Verwendung einer normalen Abfrage statt einer berechneten Spalte getan sein oder? Du bildest Deine "berechnete Spalte" erst in der Abfrage und die verwendest Du dann weiter, statt der Tabelle.

 

[andyfau]

Hallo Markus,

berechnete Spalten und Nachschlagefelder in Tabellen verursachen regelmäßig Schwierigkeiten. Salopp gesagt: Kannste vergessen. Sie sind wohl nur eingebaut worden, weil Nutzer keine Abfragen und darauf basierende Formulare erstellen wollten. Wie @dabadepdu bereits sagt, mal anders formuliert:
Tabellen und die Felder darin sollten atomar, ohne Redundanzen angelegt sein. Tabellen dann über Schlüssel/Fremdschlüssel in Beziehung gesetzt. Berechnungen gehören in Abfragen und ggf. Formulare/Berichte. Zeige mal das Beziehungsfenster deiner DB. Oder besser, Lade eine abgespeckte, anonymisierte Version der DB hier hoch.

 

[mareinki]

Danke für die raschen Rückmeldungen.
Anbei übermittle ich euch eine gleich meine Datenbank mit ein paar Test-Einträgen in den Tabellen Sportart und Tagebuch.

Wundert euch nicht, dass in der Tabelle Saisonen auch Jahreszeiten etc vorkommen (das benötige ich nämlich auch für meinen 2. Datenbank die Energieverbräuche auswertet).

Grüße
Markus

 

[andyfau]

Hallo,
ich habe mal kurz einen Blick auf die DB geworfen. Wie bereits gesagt, ist das ja keine DB im klassischen Sinn. Es sind über Nachschlagefelder verknüpfte Tabellen. Genau das macht es schwierig die Tabellen in weiteren Abfragen vernünftig zu nutzen, weil Access schon intern, wegen der Nachschlagefelder eigene Abfragen generiert.
Besser ist es keine Nachschlagefelder zu verwenden, sondern die Tabellen erstmal vernünftig über Beziehungen zu verknüpfen. Diese werden dann ja automatisch in Abfragen genutzt, bzw. vorgeschlagen.
Alle Eingaben, bzw. die Datenpflege sollten dann über Formulare und nicht direkt in die Tabellen erfolgen. Das eröffnet Dir alle Möglichkeiten die Eingabedaten zu prüfen und berechnete Felder und Summen zu generieren. Deshalb sollten die Formulare, wo Du ja offensichtlich noch garnicht tätig warst, möglichst auch nicht direkt auf die Tabellen, sondern auf entsprechende Abfragen basieren.
Ich empfehle dein theoretisches Datenbankwissen noch weiter aufzufüllen. Ohne das geht es nicht. Access ist nicht Excel, wo man einfach mal loslegt und alles andere ergibt sich dan schon.
Schau mal unter:
Access-Tutorial: Lernen Sie Microsoft Access Datenbanken zu erstellen!

 

[mareinki]

Danke für deinen Hinweis.
Ich habe mich jetzt mittels Tutorial mal begonnen meine Sport_DB neu zu designen.
Ich scheitere aber leider schon beim Anlegen eines einfachen Formulars zur Eingabe neuer Datensätze für Land/Region .

Ich habe eine Tabelle für die Länder angelegt (T_Land) und eine Tabelle für die Regionen (T_Region) und habe diese Tabellen mittels einer Abfrage wie folgt verknüpft

SELECT T_Land.Land, T_Region.Region
FROM T_Land INNER JOIN T_Region ON T_Land.ID_Land = T_Region.ID_Land;

Damit müsste ich eigentlich die DB-Normalisierungsregeln erfüllt haben.

Für die Eingabe neuer Regionen und Länder möchte ich jetzt ein Formular nutzen.

Lt. Tutorial müsste dies über ein Formular mit Kombinationsfeldern funktionieren.
Die Erstellung des Formulars (F_Land_Region) mit der Anzeige der bereits bestehenden Einträge funktioniert zwar, ich kann ein neues Land eingeben, aber die Region dazu nicht.
Habe heute sicher ein paar Stunden herumprobiert, aber funktioniert nicht.

 

[andyfau]

Guten Abend,
ich habe mir das angesehen. Prinzipiell bist Du auf dem richtigen Weg. Die Tabellen waren weitgehend ok. Nur in der T-Sportart war die Region als Textfeld eingerichtet. Der Fremdschlüssel muss hier aber die RegionID sein. Das habe ich geändert und dann über eine Änderungsabfrage (können wir später drüber sprechen) die richtigen IDs eingetragen und dann das Texfeld Region gelöscht, weil das dann ja eine Redundanz ergeben hätte.
Der nächste Punkt war: Beziehungen werden, was die Datenbankstruktur angeht, nicht in Abfragen definiert. Dies geschieht unter Datenbanktools/Beziehungen. Darüber ergeben sich dann die internen Prüfungen der Integrität der Tabellen zueinander. Als nächstes habe ich das Formular fmLand mit Unterformular UfmRegion mithilfe des Formulargenerators erzeugt. Das geht schnell und gewährleistet die richtige Verknüpfung von HF und UF. Die Abfrage qLand_Regionen ergibt sich praktisch dann daraus, wenn man innerhalb des Formulars sich die Datenquellen ansieht. Im Unterforrmular habe ich die ID-Felder auf nicht sichtbar gesetzt. Muss nicht, macht es aber übersichtlicher.
Erst dann habe ich das Regionenfeld auf Kombinationlfeld geändert. Hier solttest Du dir die Eigenschaften mal genauer ansehen. (Datenherkunft, Spaltenanzahl, gebundene Spalte, Spaltenbreite sind hier die Stichworte.

In den Tabellen T_Sportarten und T_Tagebuch gibt es noch Normalisierungsbedarf. Z.B. das Feld Kategorie sollte in einer eigenen Tabelle abgehandelt werden, wie die Region. In der Tabelle T_Tagebuch gibt es noch das Nachschlagefeld SportartID. Das sollte auf jeden Fall entfernt werden und auch hier mit einer entsprechender Beziehung gearbeitet werden. Erst dann kann mit den Tabellen vernünftig weiter gemacht werden.

 

[mareinki]

Vielen Dank für die rasche Antwort:
Nur in der T-Sportart war die Region als Textfeld eingerichtet. Der Fremdschlüssel muss hier aber die RegionID sein.
Sorry das hatte ich noch nicht normalisiert.

Das habe ich geändert und dann über eine Änderungsabfrage (können wir später drüber sprechen) die richtigen IDs eingetragen und dann das Texfeld Region gelöscht, weil das dann ja eine Redundanz ergeben hätte.
Verstehe ich

Der nächste Punkt war: Beziehungen werden, was die Datenbankstruktur angeht, nicht in Abfragen definiert. Dies geschieht unter Datenbanktools/Beziehungen. Darüber ergeben sich dann die internen Prüfungen der Integrität der Tabellen zueinander.
Das ist mir nun klarer

Als nächstes habe ich das Formular fmLand mit Unterformular UfmRegion mithilfe des Formulargenerators erzeugt. Das geht schnell und gewährleistet die richtige Verknüpfung von HF und UF.
Meinst du mit Formulargenerator den Formular-Assistenten?

Die Abfrage qLand_Regionen ergibt sich praktisch dann daraus, wenn man innerhalb des Formulars sich die Datenquellen ansieht. Im Unterforrmular habe ich die ID-Felder auf nicht sichtbar gesetzt. Muss nicht, macht es aber übersichtlicher.
Erst dann habe ich das Regionenfeld auf Kombinationsfeld geändert. Hier solttest Du dir die Eigenschaften mal genauer ansehen. (Datenherkunft, Spaltenanzahl, gebundene Spalte, Spaltenbreite sind hier die Stichworte.
Verstehe ich

In den Tabellen T_Sportarten und T_Tagebuch gibt es noch Normalisierungsbedarf. Z.B. das Feld Kategorie sollte in einer eigenen Tabelle abgehandelt werden, wie die Region. In der Tabelle T_Tagebuch gibt es noch das Nachschlagefeld SportartID. Das sollte auf jeden Fall entfernt werden und auch hier mit einer entsprechender Beziehung gearbeitet werden. Erst dann kann mit den Tabellen vernünftig weiter gemacht werden.
werde ich jetzt angehen

Ich habe noch folgende Fragen:
a) Abfrage qLand-Region
Wenn ich die Abfrage qLand-Region ausführe, bekomme ich die Fehlermeldung; Parameterwert eingeben "Formulare!fmT_Land!DLand"
Deine Abfrage lautet:
SELECT T_Region.ID_Region, T_Region.Region
FROM T_Land INNER JOIN T_Region ON T_Land.ID_Land = T_Region.ID_Land
WHERE (((T_Land.ID_Land)=[Formulare]![fmT_Land]![ID_Land]));

Eigentlich wäre die Abfrage so eigentlich ausreichend, oder?
SELECT T_Region.Region,T_Land.Land
FROM T_Land INNER JOIN T_Region ON T_Land.ID_Land = T_Region.ID_Land
Zeigt die Daten alle Länder mit ihren Regionen an.

b) in T_Tagebuch ist die Tabelle T-Sportart verknüpft über das Feld Sportart-ID. Bei der Datensatzherkunft ist Folgendes eingetragen
SELECT [ID] AS xyz_ID_xyz, [Kategorie] & ', ' & [Region] & ', ' & [Streckenbezeichnung] AS Kategorie_Region_Strecke, [Streckenverlauf] FROM T_Sportart ORDER BY [Kategorie], [Region], [Streckenbezeichnung];
Woher kommt dieser Ausdruck? Hat sich der automatisch durch die Definitionen/Beziehungen ergeben ergeben oder ist das dein Werk

Wie du richtig angeführt hast muss ich Ähnliches für die Verknüpfung der Region über die Region-ID aus der Tabelle T_Region machen, aber was gebe ich da bei Datensatzherkunft ein. Diese Logik habe ich noch nicht verstanden.
Müsste da dann sowas stehen?
SELECT [ID] AS xyz_ID_xyz, [Land] & ', ' & [Region] AS Land_Region FROM T_Land INNER JOIN T_Region ORDER BY [Region];
funktioniert aber nicht !!
Bekomme die Fehlermeldung "Parameterwert eingeben " Region ....

Und ich habe 2 Abfragen (einmal nach Jahr, einmal nach Sportart gruppiert) gemacht, die schon mal ganz gut aussehen.


Grüße
Markus

 

[andyfau]

Meinst du mit Formulargenerator den Formular-Assistenten?

Ja genau.

Eigentlich wäre die Abfrage so eigentlich ausreichend, oder?

Nein, denn die Where-Klausel ist notwendig weil sie den Filter für das Formular bildet. Btw. Ich bin kein SQL-Spezi, deshalb nutze ich eigentlich immer die Entwicklungsansicht der Abfragen. Da gibt selten Probleme mit der Syntax.

Woher kommt dieser Ausdruck?

Das hat wohl Access verbrochen, weil Du ein Nachschlagefeld in der Tabelle deklariert hast. Raus mit Nachschlagefeldern aus allen Tabellen!

funktioniert aber nicht !!
Bekomme die Fehlermeldung "Parameterwert eingeben " Region ....

Schau ich mir später nochmal an.....

 

[andyfau]

Mit den Abfragen kannst Du ja nun spielen, wie du möchtest. Aber eigentlich ist die DB ja noch nicht soweit. Wie gesagt, weitere Normalisierung ist nötig, wie oben beschrieben, z.B über das Feld Kategorie. Die Kategorien verlangen nach einer eigenen Tabelle, wie auch die Regionen. Und werfe endlich die Nachschlagefelder aus Sportarten raus! Die verursachen das Chaos mit den Selecteinträgen. Stelle in den Tabellen die Felder von Listenfeld auf Textfeld zurück. Außerdem fehlen vernünftige Eingabeformulare für Sportarten und Tagebuch, so wie ich dir das Beispielformular gebaut habe.Eingaben direkt in Tabelle macht man, ausser mit ein paar Testdatensätzen, nicht. Erstmal Daten sauber und geprüft über Formulare erfassen und dann Abfragen zur Auswertung schreiben.
Magst Du SQL so sehr, dass Du die Statements postest? Nutze als Newbee doch erstmal die Instrumente die Access bietet (Entwurfsassistenten für Tabellen, Abfragen Formulare und Berichte) und analysiere dann, was der Assistent die gebaut hat, indem Du dir dann die Eigenschaften der Objekte in Ruhe mal anschaust. Ich könnte ja jetzt die Dinge weiterbauen, aber, das ist ja nicht Sinn der Geschichte.

 

[mareinki]

Hallo
Ich habe jetzt die Tabellen Sportart und Tagebuch bereinigt (Nachschlagefelder bereinigt, eigene Tabelle Kategorie).
Weiters habe ich ein Formular Sportart mit Unterformular Tagebuch erstellt.

Was mir jetzt anliegen wäre das Eingabeformular für neue Aktivitäten (also das Formular Sportart bzw. Tagebuch) so zu gestalten, dass ich für die Eingabe neuer Aktivitäten neue Datensätze nicht über die "Pfeile" unten im Formular machen muss.

Ideal wäre ich wenn zuerst die Daten wie Datum, Zeit, Puls, etc. eingeben könnte und dann in einem Auswahlfeld aus der Liste der Sportarten auswählen könnte.

 

[andyfau]

Um Datensatzoperationen, wie gehezu Nächster, Voriger, Neuen, etc. kannst Du den Steuerelemente-Assistenten nutzen. Gehe dazu in der Entwurfsansicht unter Reiter Entwurf auf den kleinen Pfeil rechts. Wähle dort "Steuerelement-Assisten aktivieren". Jetzt öffnet sich immer dann, wenn Du ein Steuerelement, z.B. einen Button, einfügst der Assistent und hilft. Für den Anfang ist das OK. Der Assistent erstellt intermn entsprechende Macros, die die Aktionen dann ausführen. Wenn Du später mal fit in VBA bist ist es besser das in VBA zu machen. Das muss man dann aber nicht neu machen, sondern man kann Macros dann in VBA-Code umwandeln.
Die Reihenfolge der Felder richtet sich in erster Linie nach der Reihenfolge in der zugrundeliegenden Tabelle oder Abfrage. In zweiter Linie richtet sie sich nach der Reihenfolge, wie sie im Formularentwurf sind. Die Reihenfolge, wie die Felder im Formular nit der Tab-Taste angesprungen werden kann man auch in den Eigenschaften der Felder einstellen.

 

[mareinki]

Danke
Ich kann zwar "Steuerelement-Assistenten verwenden" anklicken, und wähle dann zB als Steuerelement "Schaltfläche" aus, aber es passiert nichts (also es öffnet sich kein Assistent, der Text wird nicht grau als Zeichen dass es ausgewählt wurde)
Wenn ich dann die Schaltfläche im Formular platziert habe, kann ich in den Eigenschaften auswählen was beim Klicken passieren soll: aber es ist nur Eigenschaftsprozedur auswählbar (siehe Screenshot) und wenn ich dann auf die ... klicke öffnet sich das VBA Fenster .
Bin ich da komplett falsch unterwegs?

 

[mareinki]

Hallo
Ich habe jetzt ein Eingabeformular (frm_Eingabeneue Aktivität) für neue Aktivitäten insoferne erstellt, dass ich in den Formularentwurf einerseits die Felder der Tabelle T_Tagebuch eingefügt habe und zusätzlich ein Kombinationsfeld mit Datensatzherkunft T_Sportart und in diesem Kombinationsfeld dann die Spaltenanzahl auf 5 gestellt habe und nur die Spalten 4 und 5 sichtbar gemacht habe (das sind die Spalten mit den relevanten Inhalten Streckenbezeichnung und Streckenverlauf). Damit kann ich neue Aktivitäten (neue Datensätze in T-Tagebuch) erstellen
Das sollte ok sein so oder?
Was jetzt noch schön wäre wenn bei Aufrufen dieses Formulars immer automatisch auf einen neuen Datensatz springen würde (auch um nicht irrtümlich einen bestehenden Datensatz zu überschreiben).

 

[andyfau]

Schau mal in den Datenbankoptionen (Datei/Optionen), ob irgendwo die Assistenten abgeschaltet sind. Müsste ich jetzt auch googlen.

Um auf einen neuen Datensatz beim Öffnen zu springen, könntest Du "beim Öffnen" eine Ereignisprozedur einfügen und dort:

 DoCmd.GoToRecord , , acNewRec