Datensatz anlegen in 1:1 Beziehung

Computer: Software & Programmierung Microsoft Access
#1

Hallo, ihr Klugen,
ich habe zwei Tabellen Rechnung und Zahlung. Beide Tabellen sind über eine 1:1-Verküpfung über das Feld Rechnungsnummer (Long Integer) verbunden (ref. Integrität, Lösch- und Änderung ist aktiviert).

In einer Abfrage habe ich folgende Felder mit einfachen Bedingungen integriert:

Rechnung.Rechnungsnummer
Zahlung.bezahlt am (nicht wie „*“)
Rechnung.Storno (= nein)

Den Verknüpfungstyp habe ich in der Abfrage so gesetzt, dass alle Datensätze von Rechnung erscheinen und nur die von Zahlung, die die gleiche Rechnungsnummer haben.

Wenn ich die Abfrage aufrufe, erscheinen die gewünschten Datensätze. Wenn ich jetzt die Daten der Tabelle Zahlung ausfülle, setzt Access das Feld Rechnung.Rechnungsnummer auf 0!!! Das passiert auch, wenn ich in den Beziehungen die Aktualisierungsweitergabe von Rechnung und Zahlung deaktiviere. Ich selbst kann dann zwar das Feld Rechnungsnummer in den Tabellen direkt nicht entgegen der Integrität verändern, über die Abfrage scheint das aber doch zu gehen.
Es gibt vorher keine Rechnung mit Rechnungsnummer 0, erst nach Dateneingabe in der Abfrage.

Gleichzeitig wird in der Tabelle Zahlung ein Datensatz angelegt mit den eingebenen Daten und der Rechnungsnummer 0.

Warum wird die Rechnungsnummer auf 0 gesetzt? Wo liegt der Fehler? Hat alles vorher funktioniert, habe nur ein neues Feld für die Rechnungsnummer kreiert auf das sich jetzt alles bezieht. Seit dem klappt die Abfrage nicht mehr.

#2

Hallo, Klaus!

ich habe zwei Tabellen Rechnung und Zahlung. Beide Tabellen
sind über eine 1:1-Verküpfung über das Feld Rechnungsnummer
(Long Integer) verbunden (ref. Integrität, Lösch- und Änderung
ist aktiviert).

In einer Abfrage habe ich folgende Felder mit einfachen
Bedingungen integriert:

Rechnung.Rechnungsnummer
Zahlung.bezahlt am (nicht wie „*“)
Rechnung.Storno (= nein)

Den Verknüpfungstyp habe ich in der Abfrage so gesetzt, dass
alle Datensätze von Rechnung erscheinen und nur die von
Zahlung, die die gleiche Rechnungsnummer haben.

Damit erzeugst Du für eine Zahlung einen neuen Datensatz. Und wenn Du das in der normalen Abfrageansicht tust, wird die ID mit dem Defaultwert des Feldes belegt, sehr wahrscheinlich eben 0. Und da die Aktualisierungsweitergabe eingeschaltet ist, wird diese 0 auf den Datensatz in Rechnungen weitergegeben. Blende dazu einfach mal das Rechnungsnummerfeld aus Zahlungen mit ein.

Mein Vorschlag wäre: Keine Änderung in einer Abfrage, sondern in einem Formular. Hier kannst Du dann ereignisgesteuert die Rechnungsnummer aus den Rechnungen setzen. Oder Du verwendest ein Formular für die Rechnungen, in das Du ein Unterformular verknüpft auf die Rechnungsnummer (LinkChild/MasterFields bzw. Verknüpfen von/nach) für die Zahlungen einbaust. Dann wird das automatisch gesetzt.

Wenn ich die Abfrage aufrufe, erscheinen die gewünschten
Datensätze. Wenn ich jetzt die Daten der Tabelle Zahlung
ausfülle, setzt Access das Feld Rechnung.Rechnungsnummer auf
0!!! Das passiert auch, wenn ich in den Beziehungen die
Aktualisierungsweitergabe von Rechnung und Zahlung
deaktiviere. Ich selbst kann dann zwar das Feld
Rechnungsnummer in den Tabellen direkt nicht entgegen der
Integrität verändern, über die Abfrage scheint das aber doch
zu gehen.
Es gibt vorher keine Rechnung mit Rechnungsnummer 0, erst nach
Dateneingabe in der Abfrage.

Siehe eben oben.

Warum wird die Rechnungsnummer auf 0 gesetzt? Wo liegt der
Fehler? Hat alles vorher funktioniert, habe nur ein neues Feld
für die Rechnungsnummer kreiert auf das sich jetzt alles
bezieht. Seit dem klappt die Abfrage nicht mehr.

siehe auch oben. Vorher wird das nicht wirklich funktioniert haben…

Wenn Du übrigens nicht wirklich viel in den Zahlungen stehen hast, z. B. nur das Zahlungsdatum, dann würde ich mir u. U. gar nicht den Stress machen, eine eigene Tabelle zu spendieren.

Gruß, Manfred

#3

Hallo,

kann Manfred nur beipflichten, alles in eine Tabelle zu verfrachten und auf 1:1-Tabellenbeziehungen grundsätzlich zu verzichten…Die sind unnötig wie ein Kropf und produzieren nur Ärger.

Wenn es mehrere Zahlungen pro Rechnung geben darf/soll/wird, ist eine 1:n-Tabellenbeziehung mit Datenbearbeitung über eine Haupt-/Unterform-Konstruktion zu empfehlen, bei der die beteiligten Schlüsselfelder durch Access selber „gehandelt“ werden.

#4

Vielen Dank erst einmal für eure Antwort.
Die Idee, dass über eine einzige Tabelle zu lösen, ist erst einmal super. Weiß gar nicht, warum ich das nicht gleich so gemacht habe. Na ja, die DB gibts es schon 15 Jahre, man lernt ja immer dazu.

Mein Vorschlag wäre: Keine Änderung in einer Abfrage, sondern
in einem Formular. Hier kannst Du dann ereignisgesteuert die
Rechnungsnummer aus den Rechnungen setzen. Oder Du verwendest
ein Formular für die Rechnungen, in das Du ein Unterformular
verknüpft auf die Rechnungsnummer (LinkChild/MasterFields bzw.
Verknüpfen von/nach) für die Zahlungen einbaust. Dann wird das
automatisch gesetzt.

Ich habe das alles in ein Formular eingebettet. Das Unterformular basiert auf der beschriebenen Abfrage. Und wie gesagt: vor Änderung des Feldes Rechnungsnummer hat alles funktioniert. Vielleicht gibts es irgendwo noch eine Ereignisprozedur, die ich nicht angepasst habe.

Warum aber die Daten in der Tabelle Rechnung verändert werden, obwohl die Aktualisierungweitergabe deaktiviert wurde, ist mir völlig rätselhaft. Und - ich muss sagen - es beunruhigt mich!

#5

Hab mir eben nochmal eine eine alte Version der Abfrage angesehen - mit dem alten Feld Re-Nr. Da klappt wirklich alles. Aber ein Unterschied ist mir aufgefallen: das alte Feld war ein Text, jetzt ist Rechnungsnummer eine Zahl! Damit muss es zusammenhängen.

#6

Moin,

da hättest du aber genauer lesen sollen - wegen ein zwei Felder lohnt keine 1:1-Beziehung nach Manfred und da hat er natürlich Recht!

Generell auf 1:1-Beziehungen zu verzichten ist absolut falsch. Also nach der Aussage stufe ich dich erstmal als Entwickler ein ;o))

Nicht umsosnt gibt es Normalisierungsregeln. Die sollte man sicherlich auch nicht bis ins letzte durchzeihen, aber auch nicht ganz ausser acht lassen.

Gruß

Bernd

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#7

Hallo,

mhmm, was willst (mir) Du nun mit diesem Posting sagen???

da hättest du aber genauer lesen sollen -

Was hab ich nicht genau gelesen?

wegen ein zwei
Felder lohnt keine 1:1-Beziehung nach Manfred und da hat er
natürlich Recht!

hab ich was Anderes gesagt?

Generell auf 1:1-Beziehungen zu verzichten ist absolut falsch.

Absolut ??? sag mir einen Fall, wo eine 1:1 Beziehung von Vorteil ist

Also nach der Aussage stufe ich dich erstmal als Entwickler
ein ;o))

Ja, und weiter??

Nicht umsosnt gibt es Normalisierungsregeln.

in der Tat …

Die sollte man
sicherlich auch nicht bis ins letzte durchzeihen, aber auch
nicht ganz ausser acht lassen.

Bist Du Politiker? :wink:

#8

Moin,

sag mir einen Fall, wo eine 1:1 Beziehung von
Vorteil ist

wenn ein Subtyping angebracht ist und für die Teilmengen zB unterschiedliche Zugriffsrechte eingerichtet werden sollen.

Gruß Ralf

#9

Hallo,

wenn ein Subtyping angebracht ist und für die Teilmengen zB
unterschiedliche Zugriffsrechte eingerichtet werden sollen.

Ja, wobei selbst das über Abfrage-Projektion zu lösen wäre.

Auch das Argument " sehr viele Felder" zieht nicht, weil das wiederum mit „Normalisierung“ erschlagen werden kann.

Gruß
Franz

#10

Moin, Franz,

Ja, wobei selbst das über Abfrage-Projektion zu lösen wäre.

über die Frage, ob der Admin oder der Programmierer die Berechtigungen regeln soll, ließe sich stundenlang diskutieren :smile:

Auch das Argument " sehr viele Felder" zieht nicht, weil das
wiederum mit „Normalisierung“ erschlagen werden kann.

Natürlich nicht. In 30 Jahren ist mir keine Tabelle begegnet, die mehr als 20 Felder hatte - Normalisierung vorausgesetzt (und Pipikram wie LetzteÄnderung, Anlagedatum, LetzterZugriff, Anleger, Änderer nicht gezählt).

Gruß
Franz