- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#51
Bericht / Re: Problem im Bericht
Letzter Beitrag von kisslinger - April 24, 2026, 09:19:03Hallo, danke für die Info. DB Hochladen möchte ich nicht unbedingt. Wie geschrieben werden die Mitarbeiter gruppiert und werden dann im Gruppenfuss jeweils die Zahlen der einzelnen Monate zusammengefasst. Bei allen Mitarbeitern stimmt das Ergebnis, nur bei einem wird falsch zusammengefasst. Ich kann keinen Zusammenhang mit den anderen Zahlen erkennen ob hier z.B. ein Wert nicht zusammen gezählt wird. Es steht einfach ''irgendein'' Wert da. Komisch ist wenn ich den Bericht in der Layoutansicht öffne stimmt der Wert, wechsle ich zurück in die Berichtsansicht ist der Wert dann wieder falsch. Egal, vielleicht finde ich den Fehler noch und sonst kann ich ja die richtigen Werte in der Layoutansicht sehen.
Danke auf alle Fälle für Eure Versuche zu helfen.
lg Günther
Danke auf alle Fälle für Eure Versuche zu helfen.
lg Günther
#52
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Knobbi38 - April 23, 2026, 18:58:07Zitat von: Christian72"Kann eine Firma mehrere verschiedene Zahlungsziel-Frachtkosten haben?":Dann der PK von Zahlungsziel-Frachkosten als Fremdschlüssel in Firma mitgeführt werden und das Feld Firma_ID in Zahlungsziel-Frachkosten entfällt somit.
Grundsätzlich: nein
Spezf.Sondervereinbarungen sind dann eher Auftragsbezogen und gehören dann auch dort hin.
Möglicherweise ist das Buch von A.Stern und dem Tool
http://www.buch.andreasstern.de/adamo.php
etwas für dich?
Knobbi38
#53
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Christian72 - April 23, 2026, 15:37:51Hallo Knobbi,
"Kann eine Firma mehrere verschiedene Zahlungsziel-Frachtkosten haben?":
Grundsätzlich: nein
Es ist natürlich nie auszuschließen, dass ein Kunde für ein bestimmtes (ev. großes?) Projekt einen höheren Nachlaß und ev. auch andere Zahlungsbedingungen einfordert.
In den 13 Monaten, in denen ich das hier mache, ist das allerdings noch nie vorgekommen.
Also: nein
Hallo Bitsqueezer,
´tschuldigung.
Wenn ich in ´s Beziehungsfenster geschaut habe, war das immer im Frontend. Habe ich nie d´rüber nach gedacht; bis heute.
O.k.: Also ist das nächste ToDo, in der Frontend-Datei vorsichtig alles im Beziehungsentwurf zu löschen und im Backend-Beziehungsentwurf "nachzubauen".
Melde mich, wenn das erledigt ist.
Vielen Dank euch beiden
Christian
"Kann eine Firma mehrere verschiedene Zahlungsziel-Frachtkosten haben?":
Grundsätzlich: nein
Es ist natürlich nie auszuschließen, dass ein Kunde für ein bestimmtes (ev. großes?) Projekt einen höheren Nachlaß und ev. auch andere Zahlungsbedingungen einfordert.
In den 13 Monaten, in denen ich das hier mache, ist das allerdings noch nie vorgekommen.
Also: nein
Hallo Bitsqueezer,
´tschuldigung.
Wenn ich in ´s Beziehungsfenster geschaut habe, war das immer im Frontend. Habe ich nie d´rüber nach gedacht; bis heute.
O.k.: Also ist das nächste ToDo, in der Frontend-Datei vorsichtig alles im Beziehungsentwurf zu löschen und im Backend-Beziehungsentwurf "nachzubauen".
Melde mich, wenn das erledigt ist.
Vielen Dank euch beiden
Christian
#54
Bericht / Re: Problem im Bericht
Letzter Beitrag von Bitsqueezer - April 23, 2026, 11:45:59Hallo,
ich würde zunächst mal die genaue Differenz ermitteln und oft ergibt sich an der Zahl dann, welche Daten dann falsch zusammengefaßt sind.
Ansonsten kann man eine Menge Dinge in einem Bericht falsch konfigurieren, aber dazu müßte man schon den Bericht selbst in einer Beispieldatenbank haben.
Du könntest auch eine Kopie der Datenbank erstellen und dann in der Kopie die Daten auf z.B. 3 Mitarbeiter und wenige (glatte) Umsatzzahlen reduzieren und es dort nochmal probieren. Damit kann man ebenfalls eingrenzen, was das Problem sein könnte.
Gruß
Christian
ich würde zunächst mal die genaue Differenz ermitteln und oft ergibt sich an der Zahl dann, welche Daten dann falsch zusammengefaßt sind.
Ansonsten kann man eine Menge Dinge in einem Bericht falsch konfigurieren, aber dazu müßte man schon den Bericht selbst in einer Beispieldatenbank haben.
Du könntest auch eine Kopie der Datenbank erstellen und dann in der Kopie die Daten auf z.B. 3 Mitarbeiter und wenige (glatte) Umsatzzahlen reduzieren und es dort nochmal probieren. Damit kann man ebenfalls eingrenzen, was das Problem sein könnte.
Gruß
Christian
#55
Bericht / Re: Problem im Bericht
Letzter Beitrag von Knobbi38 - April 23, 2026, 11:45:45Hallo Günther,
leider reichen die Informationen nicht aus, um eine konkrete Hilfestellung zu geben. Hierzu müsste man wissen, auf welcher Basis der Bericht erstellt wurde, nach welchen Kriterien die Gruppierungen erfolgen und wie die Summen berechnet werden. Am einfachsten lädst du eine Beispiel-DB hoch, anhand derer das Verhalten dann nachvollzogen werden kann.
Knobbi38
leider reichen die Informationen nicht aus, um eine konkrete Hilfestellung zu geben. Hierzu müsste man wissen, auf welcher Basis der Bericht erstellt wurde, nach welchen Kriterien die Gruppierungen erfolgen und wie die Summen berechnet werden. Am einfachsten lädst du eine Beispiel-DB hoch, anhand derer das Verhalten dann nachvollzogen werden kann.
Knobbi38
#56
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Bitsqueezer - April 23, 2026, 11:41:06Hallo,
OK, wenn Du solche Feinheiten nicht mitteilst, kann man schlecht eine Aussage treffen.
Wenn Du ein Backend hast, gehören ALLE Tabellen in das Backend. Ausnahmen sind lediglich ausschließlich lokal genutzte Tabellen (z.B. für Usersettings etc.). Die dann aber auch nie eine Beziehung zu Tabellen im Backend haben!
Beziehungen werden ausschließlich im Backend erstellt, alles andere sind schlicht keine Beziehungen, sondern nur "Abfragevorlagen".
Access hat die unselige Angewohnheit, das Beziehungsfenster für beides zu nutzen. Du kannst hier also auch "Verbindungen zwischen Tabellen" erstellen, die einfach nur einen JOIN darstellen wie in einer Abfrage. Da Du die gleiche Tabelle für verschiedene Verbindungen erstellen kannst, erzeugt Access automatisch ein künstliches "_1" usw. für jedes weitere Vorkommen. Die Tabelle ist dennoch immer die gleiche.
Vergiß dieses - sorry MS - idiotische Feature von Access, der Beziehungseditor soll nur verwendet werden, wenn man echte Beziehungen erstellen will, der ist auch so schon "eng" genug, weil man nur ein Diagramm haben kann. Man kann leider auch nicht im Diagramm unterscheiden, ob es eine echte Beziehung ist oder nicht. Wenn es ein "JOIN-Entwurf" ist (den neue Abfragen dann als Vorlage verwenden), kannst Du natürlich nie eine RI einstellen.
Also: Alles lokale im Beziehungseditor rauswerfen und alles korrekt im Backend erstellen. Dann gibt es auch keine RI-Probleme.
Und: Sobald Du eine Tabelle mit "_1" usw. siehst, ist schon was falsch. In einem Beziehungseditor kommt jede Tabelle nur genau einmal vor.
Gruß
Christian
OK, wenn Du solche Feinheiten nicht mitteilst, kann man schlecht eine Aussage treffen.
Wenn Du ein Backend hast, gehören ALLE Tabellen in das Backend. Ausnahmen sind lediglich ausschließlich lokal genutzte Tabellen (z.B. für Usersettings etc.). Die dann aber auch nie eine Beziehung zu Tabellen im Backend haben!
Beziehungen werden ausschließlich im Backend erstellt, alles andere sind schlicht keine Beziehungen, sondern nur "Abfragevorlagen".
Access hat die unselige Angewohnheit, das Beziehungsfenster für beides zu nutzen. Du kannst hier also auch "Verbindungen zwischen Tabellen" erstellen, die einfach nur einen JOIN darstellen wie in einer Abfrage. Da Du die gleiche Tabelle für verschiedene Verbindungen erstellen kannst, erzeugt Access automatisch ein künstliches "_1" usw. für jedes weitere Vorkommen. Die Tabelle ist dennoch immer die gleiche.
Vergiß dieses - sorry MS - idiotische Feature von Access, der Beziehungseditor soll nur verwendet werden, wenn man echte Beziehungen erstellen will, der ist auch so schon "eng" genug, weil man nur ein Diagramm haben kann. Man kann leider auch nicht im Diagramm unterscheiden, ob es eine echte Beziehung ist oder nicht. Wenn es ein "JOIN-Entwurf" ist (den neue Abfragen dann als Vorlage verwenden), kannst Du natürlich nie eine RI einstellen.
Also: Alles lokale im Beziehungseditor rauswerfen und alles korrekt im Backend erstellen. Dann gibt es auch keine RI-Probleme.
Und: Sobald Du eine Tabelle mit "_1" usw. siehst, ist schon was falsch. In einem Beziehungseditor kommt jede Tabelle nur genau einmal vor.
Gruß
Christian
#57
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Knobbi38 - April 23, 2026, 11:40:48Hallo Christian72,
mal eine Frage:
Kann eine Firma mehrere verschiedene Zahlungsziel-Frachtkosten haben?
Knobbi38
mal eine Frage:
Kann eine Firma mehrere verschiedene Zahlungsziel-Frachtkosten haben?
Knobbi38
#58
Bericht / Problem im Bericht
Letzter Beitrag von kisslinger - April 23, 2026, 10:32:54Dabei habe ich einen komischen Effekt.
Es werden pro Mitarbeiter pro Monat die einzelnen Umsatzergebnisse dargestellt und am Gruppenende jeweils die Summe der ausgewählten Monate.
Doch beim letzten Mitarbeiter ist wird die Summe der Monate im Bericht falsch ausgerechnet, wenn ich den Bericht im Layout öffne dann sehe ich das richtige Summenergebnis, wechsele ich zurück auf Berichtsansicht ist die Summe wieder falsch. Ich kann auch keinen Zusammenhang mit den Monatserbebnissen erkennen, das z.B. bei diesem Mitarbeiter nur 2 Monate zusammengerechnet würden. Was könnte da falsch sein?
lg Günther
#59
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Christian72 - April 23, 2026, 10:13:00Hallo Bitsqueezer,
vielen Dank für die ausführliche Antwort.
Habe bei ID_Firma auf "Duplikate" umgestellt.
Im Beziehungsentwurf ließ sich bei "Mit referentieller Integrität" immer noch kein Haken setzen.
Dann habe ich in der Backend-Datei in den Beziehungsentwurf geschaut.
Vorweg: Bislang hatte ich immer und ausschließlich im Frontend den Beziehungsentwurf bearbeitet.
Beide Beziehungsentwürfe sehen unterschiedlich aus!
Im Backend-Beziehungsentwurf gab es die Tabelle "Firma"; "Zahlungsziel-Frachtkosten" aber nicht.
Habe diese Tabelle ergänzt, eine Verknüpfung erstellt und siehe da:
Bei "Mit referentieller Integrität" ließ sich der Haken setzen.
:-)
Nachteil: Im Frontend-Beziehungsentwurf gibt es nun eine neue Tabelle "Firma_1" die eine Verküpfung zu "Zahlungsziel-Frachtkosten" hat (siehe: Anhang). Diese neue Tabelle gibt es nur im Beziehungsentwurf; nicht in den Access-Objekten.
So ´ne Datenbank ist ´ne ganz schöne Diva, muß ich mal sagen.
Spaß beiseite:
Macht es überhaupt Sinn, in beiden Dateien Beziehungsentwürfe zu haben und dann auch noch unterschiedliche?
Vielen Dank nochmal
Christian
vielen Dank für die ausführliche Antwort.
Habe bei ID_Firma auf "Duplikate" umgestellt.
Im Beziehungsentwurf ließ sich bei "Mit referentieller Integrität" immer noch kein Haken setzen.
Dann habe ich in der Backend-Datei in den Beziehungsentwurf geschaut.
Vorweg: Bislang hatte ich immer und ausschließlich im Frontend den Beziehungsentwurf bearbeitet.
Beide Beziehungsentwürfe sehen unterschiedlich aus!
Im Backend-Beziehungsentwurf gab es die Tabelle "Firma"; "Zahlungsziel-Frachtkosten" aber nicht.
Habe diese Tabelle ergänzt, eine Verknüpfung erstellt und siehe da:
Bei "Mit referentieller Integrität" ließ sich der Haken setzen.
:-)
Nachteil: Im Frontend-Beziehungsentwurf gibt es nun eine neue Tabelle "Firma_1" die eine Verküpfung zu "Zahlungsziel-Frachtkosten" hat (siehe: Anhang). Diese neue Tabelle gibt es nur im Beziehungsentwurf; nicht in den Access-Objekten.
So ´ne Datenbank ist ´ne ganz schöne Diva, muß ich mal sagen.
Spaß beiseite:
Macht es überhaupt Sinn, in beiden Dateien Beziehungsentwürfe zu haben und dann auch noch unterschiedliche?
Vielen Dank nochmal
Christian
#60
Tabelle/Abfrage / Re: Abfrage: Verknüpfung änder...
Letzter Beitrag von Bitsqueezer - April 23, 2026, 08:56:54Hallo Christian,
41 ist schon ganz schön viel. Das bedeutet übersetzt, Du hast für 41 Firmen-IDs keine Firma in den Firmen-Stammdaten hinterlegt.
Da Du ja gesagt hast, das ID-Feld sei neu, frage ich mich, wie es zu den 41 Einträgen kam? Hast Du die Tabellen dahingehend mal inhaltlich überprüft?
Du solltest mal eine Abfrage mit den beiden Tabellen erstellen und alle Felder ausgeben lassen, verknüpft über ID_Firma zu Schlüssel. Passen die Einträge dann überhaupt zueinander?
Das Problem bei ID-Verknüpfungen ist, daß man auch leicht die falschen ID-Werte eintragen kann. Bevor Du also Daten löschst, die vielleicht noch gebraucht werden, erst mal die ID checken. Mal die alte Verknüpfung über FirmaSuch dagegenstellen und vergleichen.
Genau deswegen ist referentielle Integrität gleich zu Beginn des DB-Designs so wichtig, damit ID-Werte immer zueinander passen und garantiert ist, daß es einen PK-Eintrag in der PK-Tabelle gibt zu den FK-Einträgen anderer Tabellen.
Von Deinen Screenshots her sieht alles korrekt aus, PK, AutoID, Long Integer auf beiden Seiten. Du kannst die gleiche Abfrage auch umgekehrt formulieren, also die Firmentabelle ausgeben WHERE NOT EXISTS mit der anderen Tabelle. Wobei in den Stammdaten natürlich mehr drin sein können als in den Zahlungsziel-Daten, weil man ja nicht zwingend für jede Firma dort einen Eintrag haben muß.
Die RI kann nicht hergestellt werden, wenn die Eindeutigkeit der Verbindung nicht hergestellt werden kann. In Deinem Fall die ID-Werte auf beiden Seiten.
Oh, ich sehe da gerade noch ein Problem, was genau das verhindert: Du hast den Index für ID_Firma auf "Ohne Duplikate" eingestellt. Das würde eine 1:1-Verbindung erzeugen, dann muß es in beide Richtungen genau einen passenden ID-Eintrag geben. Also jede Firma hat genau ein Zahlungsziel. Firmen ohne Zahlungsziel sind dann nicht erlaubt.
Stelle das auf "Duplikate" um, dann ist es eine normale 1:n-Beziehung. Eine 1:1-Beziehung ist in den seltensten Fällen notwendig und viel zu schwierig zu handhaben. 1:n wäre für den Zweck auch sinnvoller, wenn Du etwa ein Gültigkeitsfeld verwendest, dann kann jede Firma mehrere haben mit einem Gültigkeitszeitraum. Oder, wenn es um Artikel geht, in Abhängigkeit eines Artikels verschiedene Zahlungsziele, usw.
Wenn Du garantieren willst, daß es immer nur einen Eintrag geben darf, kannst Du das auch im Frontend (im Formular) abfangen, ohne eine 1:1-Beziehung zu erzwingen.
Oft genügt es aber auch, wenn ohnehin eine 1:1-Beziehung besteht, die entsprechenden Felder direkt in die Firmentabelle einzutragen, dann hast Du den Stress nicht.
Gruß
Christian
41 ist schon ganz schön viel. Das bedeutet übersetzt, Du hast für 41 Firmen-IDs keine Firma in den Firmen-Stammdaten hinterlegt.
Da Du ja gesagt hast, das ID-Feld sei neu, frage ich mich, wie es zu den 41 Einträgen kam? Hast Du die Tabellen dahingehend mal inhaltlich überprüft?
Du solltest mal eine Abfrage mit den beiden Tabellen erstellen und alle Felder ausgeben lassen, verknüpft über ID_Firma zu Schlüssel. Passen die Einträge dann überhaupt zueinander?
Das Problem bei ID-Verknüpfungen ist, daß man auch leicht die falschen ID-Werte eintragen kann. Bevor Du also Daten löschst, die vielleicht noch gebraucht werden, erst mal die ID checken. Mal die alte Verknüpfung über FirmaSuch dagegenstellen und vergleichen.
Genau deswegen ist referentielle Integrität gleich zu Beginn des DB-Designs so wichtig, damit ID-Werte immer zueinander passen und garantiert ist, daß es einen PK-Eintrag in der PK-Tabelle gibt zu den FK-Einträgen anderer Tabellen.
Von Deinen Screenshots her sieht alles korrekt aus, PK, AutoID, Long Integer auf beiden Seiten. Du kannst die gleiche Abfrage auch umgekehrt formulieren, also die Firmentabelle ausgeben WHERE NOT EXISTS mit der anderen Tabelle. Wobei in den Stammdaten natürlich mehr drin sein können als in den Zahlungsziel-Daten, weil man ja nicht zwingend für jede Firma dort einen Eintrag haben muß.
Die RI kann nicht hergestellt werden, wenn die Eindeutigkeit der Verbindung nicht hergestellt werden kann. In Deinem Fall die ID-Werte auf beiden Seiten.
Oh, ich sehe da gerade noch ein Problem, was genau das verhindert: Du hast den Index für ID_Firma auf "Ohne Duplikate" eingestellt. Das würde eine 1:1-Verbindung erzeugen, dann muß es in beide Richtungen genau einen passenden ID-Eintrag geben. Also jede Firma hat genau ein Zahlungsziel. Firmen ohne Zahlungsziel sind dann nicht erlaubt.
Stelle das auf "Duplikate" um, dann ist es eine normale 1:n-Beziehung. Eine 1:1-Beziehung ist in den seltensten Fällen notwendig und viel zu schwierig zu handhaben. 1:n wäre für den Zweck auch sinnvoller, wenn Du etwa ein Gültigkeitsfeld verwendest, dann kann jede Firma mehrere haben mit einem Gültigkeitszeitraum. Oder, wenn es um Artikel geht, in Abhängigkeit eines Artikels verschiedene Zahlungsziele, usw.
Wenn Du garantieren willst, daß es immer nur einen Eintrag geben darf, kannst Du das auch im Frontend (im Formular) abfangen, ohne eine 1:1-Beziehung zu erzwingen.
Oft genügt es aber auch, wenn ohnehin eine 1:1-Beziehung besteht, die entsprechenden Felder direkt in die Firmentabelle einzutragen, dann hast Du den Stress nicht.
Gruß
Christian