Office: (Office 2007) Formulare über mehrere Tabellen

Moin,

das ist falsch. Access kann jedes beliebige Tupel updaten, wenn es alle Identifier enthält.

 

Hallo Andreas,

ganz ohne Werbung.

FireFox und Adblocker: Adblock und Ghostery.

Guten Rutsch
Rainer

 

=> Feldbezeichnung Überarbeitet
=> Schlüssel gemäß Vorschlag von ekkehard geändert
Siehe hier
Auf die zusätzlichen Schlüssel zu verzichten, bringt in Verbindung mit dem "Autowert" als Schlüssel einen großen Nachteil: in den mit 1:1 verbunden Tabellen MUSS zwingend der neue Satz in BEIDEN Tabellen den gleichen Autowert-Schlüssel besitzen. Es ist bekannt, dass Access beim Einfügen einen um 1 höheren Autowert einsetzt. Wird der Datensatz dann aber verworfen (gelöscht), ergibt sich ein Unterschied, wenn das bei nur EINER Tabelle passiert. Folge: die Verbindung kann nicht hergestellt werden => Fehler.
Ausweg: der Schlüssel ist kein Autowert, sondern ein selbst definierter Schlüssel:
Code:

Nächstes Problem:
Die Datenbank (DB) hat zum Testen zwei Formulare.
im Formular F1_test1 werden die Sätze nach Adressen, und dann nach Ansprechpartner untergliedert. Im F1_test2 werden sie nach dem Kriterium "Ansprechpartner" angezeigt.
Wie unschwer zu erkennen, bockt access in F1_test1 bei Anlage eines neuen Satzes, weil im UF die Felder noch Informationen aus einem anderen Satz anzeigen.

Ich bin fast am Ende meiner Kraft.
1:1-Verbindungen sind doch nichts ungewöhnliches und werden bei Zugriffsbeschränkungen eingesetzt. Warum gibt es hier nur Probleme?
Wie machen denn das die Profis?

 

Hurra - ein Erfolgserlebnis: Die Werbung ist weg
Danke Rainer

 

Hallo Andreas,

Nein, bei einer 1:1-Beziehung ist der PK der linken Tabelle automatisch auch
der eindeutige Schlüssel (PK) der rechten, wo er gleichzeitig ein FK ist.
Im Prinzip stellen die Felder der rechten Tabelle ja nur eine Verbreiterung der
linken dar. Will sagen wenn sie in einer Tabelle stehen würden hätten sie ja
auch nur einen PK.
Deine DB schaue ich mir an. Mal sehen wie weit ich damit komme, kann heute
nicht solange.
gruss ekkehard

 

Hallo Andreas,
Was ist das? Wo sind denn da jetzt die 1:1-Tabellen geblieben?
Bei meinen Vorschlägen in #8 bin ich von diesem (Anlage) Teil des
Beziehungsfensters ausgegangen.
Ich weiss wie gesagt nicht wann ich es schaffe, aber ich löse diesen Teil der
DB mal heraus in eine neue DB und klicke die Formulare zusammen.
gruss ekkehard

 

Hallo,

Da bringst Du aber einiges durcheinander. Nur der Primärschlüssel darf ein Autowert sein, als Fremdschlüssel darf kein Autowert verwendet werden. Der Fremdschlüssel ist dann eine Zahl (Long Integer). Der FS wird dann zum Primärschlüssel gemacht, das ergibt dann 1:1.
Primärschlüssel hat mit Autowert auch nichts zu tun.

1:1 Beziehungen sind auch nur selten sinnvoll. Ich bin der Auffassung, in Deiner DB ist keine einzige 1:1 Beziehung notwendig.
Auch der Code in #18 ist ersatzlos überflüssig. Wozu brauchst Du die höchste ID_T1Adr ?

Du programmierst zu viel.
Für die Grundfunktionalitäten dieser DB muss man nix programmieren. Das kann Access serienmäßig.

Kannst Du mal bitte die Bedeutung der Tabellen erklären, ich halte auch die Tabellenstruktur für ungeeignet.

Wenn ich mich recht erinnere, hatten wir die Disskuson in einem Deiner älteren Themen schon mal.

 

Hallo Andreas,
Ging schneller als erwartet; - siehe Anlage.
Die Formulare sind nur mit dem Assi zusammengeklickt. Da müsste also noch
einiges an Benennung der Steuerelemente und der Optik getan werden.
Das Prinzip sollte aber klar werden. Ich habe dir die relevanten Schlüsselfelder
farblich markiert.
gruss ekkehard

 

Hallo Andreas,

ich arbeite in einer DB mit sehr vielen 1:1 Beziehungen zwischen den Tabellen, aber deinen

würde ich jetzt nicht nehmen.

In Access ist das ziemlich einfach, in dem eine Tabelle mit einer ID (PK/Autowert) erstellt wird und in der abhängigen 1:1 Tabelle dieser dann als Fremschlüssel eingebunden wird. Auf diesen FK wird anschließend ein Unique Index gelegt. Der PK in der abhängigen 1:1 Tabelle ist dann wiederum ein ID Feld mit einem Autowert.

Ulrich

 

Zuerst zum post von gpswanderer:
Hallo Klaus, aus meiner Sicht bringe ich nichts durcheinander.
Die Empfehlung war, meine Hilfsschlüssel / Fremdschlüssel zu entfernen und mit dem Primärschlüssel (PK) zu arbeiten. Das habe ich gemacht. Dann das Formular erstellt (ohne Programmieren). Um das Ergebnis im Formular prüfen zu können habe ich ein paar Datensätze händisch in die Tabelle eingefügt.
Dann meldete access Fehler beim Schreiben von neuen Datensätzen. In der Folge habe ich den PK von Autowert auf selbst zu vergebenden Wert geändert. Sonst hatte ich auch keinen Autowert. Dann die Problematik mit dem Formular (neuer Datensatz, Formular nicht leer).

Sinnhaftigkeit der Tabellen: Hintergrund ist die DSGVO. Sie besagt, dass Daten nach einem definierten Zeitraum zu löschen sind. Lösche ich innerhalb einer Tabelle die Felder, bleibt die (Speicher)Größe der DB gleich. Also: 1-1 Verknüpfung. hier kann der gesamte Satz gelöscht werden - die DB wird tatsächlich kleiner. Es hätte auch den Vorteil, den ganzen Satz zu löschen und nicht sequenziell einzelne Felder. Ich wollte es so, weil ich es mir zugetraut hatte. Ich dachte aus, es ist eine 'saubere' Lösung.
Tabellen:
T1_Adr Bezeichnet eine Adresse, unter der ein Kontakt zu finden ist (muss wegen der Datenintegrität bleiben)
T2_Adr der Teil mit den persönlichen Daten, die u.U. zu löschen sind.
T1_AsP Bezeichnet einen Kontakt zu der Adresse (muss wegen der Datenintegrität bleiben)
T2_AsP der Teil mit den persönlichen Daten der Kontaktperson, die u.U. zu löschen ist.
Die Aufspaltung zwische Adr & AsP hat den Hintergrund, dass ich verschiedene Personen zu einer Adresse anlegen kann.
Die anderen Tabelle sind (glaube ich) soweit selbsterklären. Über die Tabellen bei den Vorgängen können wir uns unterhalten, wenn die Adressen erledigt sind.

 

Zum post von Beaker s.a.
Hallo ekkehard.
Mit dem Assistenten hatte ich die Formulare auch gestaltet. Insoweit sind die Ergebnis deckungsgleich.
Jetzt kommt das Entscheidende: gebe ich bei Straße etwas ein, gibt es die Meldung : siehe screenshot[/url].
Erwarte ich von dem Formular zu viel oder übersehe ich etwas?
In so einem Moment fange ich dann normal an zu programmieren, weil access nicht macht, was es soll.

 

Zum post von knobbi.
Hallo Ulrich;
gerne verzichte ich auf extra programmierte Umwege. Wenn access es automatisch macht - gerne. Was mich am Autowert aber stört ist, dass access auch bei abgebrochenen Eingaben um 1 weiter zählt. Und scheinbar kann mit Bordmitteln der Stand vom Autowert nicht abgefragt / ausgelesen / ermittelt werden. Erst wieder beim Schreiben von einem neuen Datensatz.

Wegen der zu geringen Einsparung an Speicherplatz oder wegen der sich daraus erhöhenden Verschachtlungstiefe?
Mit der Option "Indiziert ohne Duplikate" trage ich dem Unique Index" rechnung, auch ohne Autowert.

 

Hallo Andreas,

Richtig, aber da der Wert eines Autowertes als solches prinzipiell keine Rolle spielt, ist das egal. Als Autowert könnte z.B. auch eine GUID verwendet werden und die hat auch keine sequentielle Nummerierung. Der Autowert dient der eindeutigen Identifizierung eines Datensatzes.

Jeder Feldwert kann ausgelesen werden, also verstehe ich das zunächst mal nicht, was du damit meinst. Wie o.a. verstehe ich auch nicht deine Fixierung auf den Autowert, weil das unerheblich ist und in diesem Zusammenhang keine Rolle spielt.

Wegen der zu geringen Einsparung an Speicherplatz oder wegen der sich daraus erhöhenden Verschachtlungstiefe?

Weder noch, sondern weil der Der PK als FK eingebunden wird - alles andere ist viel zu aufwändig.

Der Unique-Index über den FK realisiert die 1:1 Beziehung. Ohne Autowert als PK in der Beziehungstabelle würde es auch gehen, aber da Access das nicht kennt, mußt du dann alles selber programmieren.
Machen könnte man viel, aber diese Vorschläge, auch von den anderen Helfern hier, kommen aus der Praxis und haben schon ihre Berechtigung.

Gruß Ulrich

 

Hallo,

Der Sinn der DSGVO Tabelle erschließt sich mir nicht. Du hast auch ein falsches Verständnis der Beziehungen. Du hast eine 1:1 Beziehung der DSGVO Tabelle zur Ansprechpartnertabelle mit RI.
Das bedeutet, Du kannst in der DSGVO Tabelle keinen Datensatz löschen, solange es einen Datensatz in der Personentabelle gibt mit der gleichen ID. Das wird von Access verhindert.
Du musst also den Datensatz in der Personentabelle auch löschen, dann kannst Du auch auf die DSGVO Tabelle verzichten, die macht keinen Sinn.
In der Personentabelle werden dann einfach die persönlchen Daten geleert.
Entgegen Deiner Annahme verringert sich auch dann der Speicherplatz, weil sich der Speicherplatz nicht nach der angelegten Feldgröße richtet, sondern nach der Anzahl der tatsächlichen Zeichen im Feld. Ein leeres Feld speichert nur 2 Byte, auch wenn 255 als Feldgröße eingestellt ist.

Und Lücken im Autowert sind wie bereits gesagt völlig bedeutungslos. Der Autowert wird auch ausgeblendet und ist gar nicht zu sehen.

Wenn Du die Tabellenamen etwas weniger kryptisch wählen würdest, wäre das für einen Ausßenstehenden auch leichter zu überblicken.
Die Zusammenhänge zwischen Ansprechpartner und Adressen habe ich immer noch nicht geblickt.

Du hast, wenn ich das recht verstehe Adressen. Und zu jeder Adresse kann es mehrere Ansprechpartner geben, die auch wieder eine Adresse haben können, richtig ?
Was machst Du, wenn jemand umzieht und auch die alte Adresse gespeichert bleiben muss ?
Von daher, sind auch die 1:1 Beziehungen für die Adressentabellen nicht richtig.

 

Zu Knobbi38:
Hallo Ulrich, vielleicht gehe ich tatsächlich von falschen Voraussetzungen bei 1:1 aus. Werde nochmals im Netz recherchieren.
Zu gpswanderer:
Hallo Klaus, DSGVO Tabelle? Habe ich so nicht geschrieben. Und was ist bitte "RI"?
Auf dem Access-Lehrgang hat man mir erzählt, dass die Feldlänge den Speicherplatz bestimmt. siehe auch: https://support.office.com/de-de/art...2-36b93f966a33

Ich verwende 2010. Daraus leite ich ab: Feldgröße = Speicherbedarf.
Autowert: richtig, wird später ausgeblendet. Wenn access den Schlüssel (noch) nicht automatisch übergibt, (siehe hierzu #8) muss der Schlüssel auf eine andere Weise übergeben / ausgelesen werden.
Alle Personen , die über den Schlüssel mit einer Adresse verbunden sind, haben natürlich nur diese eine Adresse. Vergleichbar einer Firma (Standort = Adr) und deren Mitarbeiter (=AsP).
Etwas leiten lasse ich mich von dem in der Firma verwendeten Warenwirtschaftsprogramm. Ändert sich eine Adresse durch Umzug, wird die Adresse geändert oder neu angelegt oder eine Kopie geändert.