Office: (Office 2007) Formulare über mehrere Tabellen

Hallo Andreas,

man muß schon genau lesen:

Natürlich hat der Datentyp einen Einfluß auf den verwendeten Speicherplatz, z.B. bei Integer(2) und Long(4) Byte und Textfelder werden in Access dynamische gespeichert, also belegen nur den Speicherplatz, der tatsächlich gebraucht wird zuzüglich ein paar Bytes für die Verwaltung. Die Längenangabe bezieht sich auch die mögliche max. Anzahl an Zeichen.
Da wir uns aber bei Datenbanken im MByte bzw. GByte Bereich bewegen, spielt das für gewöhnlich nur eine untergeordnete Rolle und dort, wo es eine Rolle spielen würde, setzt man andere DB-Systeme ein.

"RI" ist die Abkürzung für Referentielle Integrität und wird in der Wikipedia gut erklärt.

Noch eine Anmerkung:
natürlich kann man sich bei anderen Systemen etwas abschauen und davon lernen, allerdings muß man auch die Rahmenbedingen beachten, unter dehnen sie erstellt worden sind. Z.B. bei dem WA-System würde es nach dem "reinen" DB-Modell schon reichen, eine Adresse pro Firma zu speichern, aber aus praktischen und rechtlichen Erwägungen reicht das natürlich nicht. Mit nur einer Adresse pro Firma würden bei einer Änderung sofort alle Adressangaben zu dieser Firma geändert, was allerdings bei Belegen so nicht zulässig ist. Deshalb eine 1:n Beziehung zwischen Firma und Adress-Stammdaten.

Gruß Ulrich

 

Hallo Forum,
bringen wir das Thema zu einem Ende.
Die, die meinen, mein in #3 gezeigten Tabellenfelder oder Verknüpfungen sind unpassend oder falsch, bitte ich einen anderen Entwurf vorzulegen.
Der Vorschlag in #8, siehe meine Umsetzung in #18 erscheint immer konfuser.
Im Netz steht überall, dass eine Tabelle einen Primärschlüssel braucht, und ein weiteres Feld als Fremd / oder Hilfsschlüssel für die 1:1 Verknüfung benutzt wird.
Nach derzeitigem Stand spricht mich #23 am meisten an, wegen der Fehlermeldung bei Eingabe in das Formular werde ich versuchen drum-herum zu programmieren.

 

Hallo,
RI= Referentielle Integrität.

damit meine ich die Tabelle mit dem Feld "DSGVO_gesperrt".

Das trift auch für ältere Access Versionen zu. Ich habe das so schon für A2003 gelernt.

Genau das würde ja mit 1:1 nicht funktionieren. Das muss dann 1:n werden.
Mir fehlt immer noch der Durchblick. Kannst Du mal auf meine Rückfrage eingehen ?

??
Ohne Verständnis der Zusammenhänge kann ich keinen Vorschlag machen.

Du musst keinen Schlüssel auslesen, das braucht man definitiv nicht. Wozu auch ?
Bei Hafo-Ufo Formularen wird der Schlüsselwert automatisch übergeben ohne dass man diesen kennt. Mehr braucht es nicht.

PS:
Wegen der paar Bytes die man da an Speicherplatz spart würde ich mir einen solchen Aufbau nicht antun. Wenn Daten wegen der DSGVO gelöscht werden müssen, würde ich die Felder leeren.

 

Hallo Andreas,
Meine Hinweise zum PK in der :1-Tabelle wahren nicht ganz richtig. Der
Autowert-PK ist nicht falsch, nur unnötig (IMO).
Zu deinem Problem mit dem Formular. Du musst natürlich zuerst einen DS
im HFo anlegen bevor du in den UFos die zugeordneten DS erfasst. Da
greift eben die autom. Weitergabe des PK in das FK-Feld.

Das spielt doch keine Rolle, den bekommt der Anwender im Normalfall doch
eh nie zu sehen. Dazu hat Ulrich ja auch schon einiges geschrieben.
Fortlaufende Nummern ohne Lücken muss man selber erzeugen, wobei ich
dabei auch nie auf einen AutoWert-PK verzichten würde.

Da brauchst du nichts "herum zu programmieren" wenn du o.a. Hinweis liest.
Ich weiss jetzt nicht, und hab' auch keine Lust zu suchen, ob hier schon mal
ein Hinweis auf Beschäftigung mit den Grundlagen erfolgt ist. Falls nicht, lies
mal dieses.
Und dieses Tool hilft dir bei der praktischen Umsetzung des Gelesenen/Gelernten.
gruss ekkehard

@Klaus

Wie gesagt, DSGVO ist nicht so mein Thema, aber die Idee die zu löschenden
Daten in eine 1:1 zu verlegen finde ich gar nicht so schlecht. Hier frage ich
mich allerdings ob die Felder alle in den richtigen Tabellen liegen.

 

hallo,
@Ekkehard

Welchen Vorteil siehst Du da ?
Speicherplatz ist doch keiner gespart, wenn ich die Daten in die andere Tabelle verschiebe. Und wegen der RI können auch in der 1:1 FS Tabelle keine Datensätze gelöscht werden.

So geht es mir auch, ich habe den Tabellenaufbau immer noch nicht so recht verstanden.
Mir scheint, da wird viel zu kompliziert gedacht.

 

Doch, das geht, wenn die RI über den FK erstellt wird und der FK einen Unique-Index erhält. Dann kann es keinen oder genau einen DS in der abhängigen Tabelle geben und die Löschweitergabe funktioniert auch.

Gruß Ulrich

 

Hallo Klaus,

Das verstehe ich nicht. In meinem Beispiel kann ich sowohl DS in T2_Adr
löschen als auch als Ganzes (mit Löschweitergabe in der RI) in T1_Adr.
gruss ekkehard

 

Hallo,
da war ich wohl etwas auf dem Holzweg.
In der Haupttabelle können keine DS gelöscht werden, so lange es noch Detailsätze gibt. Wenn Löschweitergabe eingestellt ist geht das Löschen der Detaildatensätze automatisch.

Sorry für die Verwirrung.

 

Hallo Forum,
Danke an alle, die in ihrer (Frei)Zeit an dem Thema mitgewirkt haben.
In der Tat macht die 1:1 Beziehung hier wirklich keinen Sinn.
Die Beiträge werden (zumindest mir hoffentlich) helfen, eine möglichst gute Struktur und Umsetzung vom Rest zu finden.
Hiermit markiere ich das Thema als erledigt.
PS: Wenn es mir möglich ist, möchte ich den Access- Stammtisch Rhein-Main besuchen. Wie es sich auch hier gezeigt hat, sollte man immer für andere Meinung zugänglich sein.