Hallo,
folgendes Problem: ich habe 2 Tabellen: tbl_Immobilie und tbl_plz. In der tbl_Immobilie gibt es die Felder "Adresse" und "PLZ" sowie diverse andere Ja/Nein-Felder, die hier nicht wichtig sind. In der tbl_PLZ gibt es die Felder "PLZ" und "Ort".
Wenn ich nun ein Formular erstelle, in dem ich die Daten zur Immobilie eintragen kann möchte ich, dass aufgrund der eingetragenen PLZ (Usereingabe) der Ort automatisch aus der tbl_PLZ ausgelesen wird und im Formular dann neben der PLZ erscheint. Bei vorhandenen Datensätzen in der tbl_Immobilie funktioniert das Formular, aber ich kann dann keine Datensätze bearbeiten oder aus dem Formular heraus neue Datensätze in der tbl_Immobilie anlegen. Jeder Versuch etwas in den Eingabefeldern zu ändern wir mir nur mit einem akustischen "Pling" quittiert.
Wer kann mir hier helfen?
Schon mal Danke vorab
Michael
Hallo,
Zitatdass aufgrund der eingetragenen PLZ (Usereingabe) der Ort automatisch aus der tbl_PLZ ausgelesen wird und im Formular dann neben der PLZ erscheint.
Du machst einen grundsätzlichen Denkfehler. Eine PLZ ist nicht eindeutig. Zu einer PLZ kann es mehrere Orte (kleinere) geben.
Du solltest daher Deiner PLZ Tabelle einen Primärschlüssel (Autowert) verpassen.
In tbl_PLZ gibt es dann die Felder "OrtID" (Autowert), "PLZ" und "Ort". PLZ muss übrigens ein Textfeld sein und keine Zahl.
Hast Du auch daran gedacht, dass eine PLZ für eine große Stadt von den Straßen abhängig ist?
Wie soll das dann gehen?
Mit einem Kombi suchst Du dann den Ort und trägst dann die OrtID (den Autowert) als Eintrag ein. Im Kombi zeigst Du die PLZ an und über eine Abfrage den Ort.
Eine solche Abfrage ist aktualisierbar/bearbeitbar.
Hallo MzKiMu,
danke für Deine schnelle Antwort. Deine Hinweise zu PLZ und Ort sind richtig, habe ich aber alles in den beiden Tabellen bereits bedacht.
Hiermit komme ich aber noch nicht klar:
ZitatMit einem Kombi suchst Du dann den Ort und trägst dann die OrtID (den Autowert) als Eintrag ein. Im Kombi zeigst Du die PLZ an und über eine Abfrage den Ort.
Eine solche Abfrage ist aktualisierbar/bearbeitbar.
Wie hilft mir denn hier ein Kombinationsfeld im Formular weiter? Und wieso den Ort suchen? Ich will doch die PLZ eingeben und der Ort soll mir dann ausgegeben werden?
1. Beispiel: ich gebe 51069 ein und ausgegeben wird dann neben der PLZ: "Köln"
2. Beispiel: ich gebe 50933 ein und ausgegeben wird: "Köln"
Habe mal einen Ausschnitt meiner Beziehungseinstellungen angehangen. Wäre super wenn Du mir hier nochmal auf die Sprünge helfen könntest. Danke
Michael
[Anhang gelöscht durch Administrator]
Hallo,
Deine Beziehungen sind ausnahmslos (zumindest die sichtbaren) alle falsch. Beziehungen laufen immer über den Primärschlüssel und niemals über den Klartext. Auch fehlt bei einige Beziehungen referentielle Integrität. Wenn sich diese nicht einstellen lässt, hast Du bereits einen Fehler im Tabellenentwurf und/oder in den Daten. Mit den falschen Beziehungen könnte auch das Problem mit der nichtbearbeitbaren Abfrage zusammenhängen.
Auch die Beziehung zwischen Objekte und Ort ist falsch. In die Tabelle Objekte muss ein Schlüsselfeld (Zahl) das auf den Primärschlüssel des Ortes verweist. Und referentielle Integrität ist einzustellen. Den Ort auch noch in der Objekttabelle zu speichern ist auch falsch.
Im Anhang ein Bild.
Das gilt für die meisten der Beziehungen und ich fürchte, bei denen die man nicht sieht ist es genau so.
Das solltest Du dringend überarbeiten.
ZitatWie hilft mir denn hier ein Kombinationsfeld im Formular weiter?
Weil Du damit gezielt die PLZ (oder den Ort, je nachdem was Du bevorzugst) wählen kannst.
Du gibst im Kombi 51069 ein und der PK der Ortstabelle wird eingetragen,
nicht! die PLZ. Über die Abfrage kannst Du automatisch auch den Ort und ggf. auch die Straße dazu ausgeben. Das geht viel einfacher, sicherer und komportabler als Du es jetzt hast. Die Auswahl im Kombi wird nämlich automatisch immer genauer.
PS:
Verwende grundsätzlich keine Leer und Sonderzeichen in Feldnamen. Das ist eine große Fehlerquelle. Z.B. "Status geändert ?" ist eine Katastrophe. Das Fragezeichen ist nämlich auch ein Jokerzeichen. In den Bezeichnungsfeldern kannst Du Dich austoben, aber nicht in den Feld und Objekt/Tabellennamen.
Und eine ID einfach ID zu nennen, bringt Dich irgendwann auch zur Weisglut, weil Du nicht mehr weist, welche ID jetzt gemeint ist. ObjektID wäre besser.
Im Anhang noch ein einfaches Beispiel bezogen auf Dein obiges Bild mit wenigen Feldern.
[Anhang gelöscht durch Administrator]
O.K., das ist hart. Aber ich wusste schon, dass mein Nickname nicht ganz realitätsfern war. Dann hoffe ich jetzt nur, dass ich mir mit den anstehenden Änderungen nicht alles komplett zerschieße.
Bis hierhin schon mal vielen Dank!
Michael
Hallo MzKlMu,
ich versuche jetzt mal Deine Ratschläge umzusetzen. Dürfte ich Dich bitte mal über den Beziehungsbericht drüberzuschauen und mir entsprechende Hinweise zu geben? Habe ich Deinen Tip richtig verstanden, dass immer eine Seite der jeweilgen Beziehung ein Indexfeld sein muss? Wie ist das denn bei der Beziehung zwischen dem Beruf eines Darlehensnehmers und der Verbindungstabelle für die m:n-Beziehung?
Gruß
Michael
[Anhang gelöscht durch Administrator]
Hallo,
Du hast immer noch Sonderzeichen und Leerzeichen in den Feldnamen. Auch das - ist ein Sonderzeichen. Die ID heißen immer noch nur ID.
Die Beziehungen passen alle nicht. Als erstes solltest Du mal allen Tabellen (sofern noch nicht vorhanden) einen Autowert als Primärschlüssel verpassen. Diesen benennst Du dann mit einem bezug zur Tabelle (MitarbeiterID, ZuführerID, TerminID usw.), für alle Tabellen. Die Personalnummer der Mitarbeiter wird nur Indiziert, ohne Duplikat aber kein Primärschlüssel.
Fremdschlüssel wird dann immer eine Zahlenfeld (Longinteger), indiziert, mit Duplikaten. Über diese Feld laufen ausschließlich die Beziehungen.
Z.B. das Feld Bearbeiter in der Tabelle Zuführungen heißt dann MitarbeiterID_Bearb_F. _F steht für Fremdschlüssel.
In den Tabellen direkt stehen beim n-Teil der Beziehung immer nur die Zahlen (die Schlüssel) keine Klartexte. Du darfst in Tabellen keine Nachschlagfelder verwenden.
Das gilt sinngemäß für alle Tabellen. Die echten Werte die sich hinter der Zahl verbergen holt man sich über Abfragen. Wie das geht erkennst Du an meinem kleinen Beispiel. An dem Du auch erkennst wie die Beziehungen anzulegen sind.
ZitatHabe ich Deinen Tip richtig verstanden, dass immer eine Seite der jeweilgen Beziehung ein Indexfeld sein muss?
Nein, nicht ganz. Beide Seiten sind ein Indexfeld. Der 1-Teil (der Primärschlüssel=PS) wird ohne Duplikate indiziert, der n-Teil (der Fremdschlüssel=FS) wird mit Duplikaten indiziert.
ZitatWie ist das denn bei der Beziehung zwischen dem Beruf eines Darlehensnehmers und der Verbindungstabelle für die m:n-Beziehung?
Wo siehst Du hier eine n:m Beziehung. Der Darlehensnehmer hat einen Beruf, also eine ganz einfache 1:n Beziehung. In der Darlehensnehmer wird der Beruf ein Zahlenfeld (Longinteger), indiziert, mit Duplikaten und dem Namen BerufID_F.
Unabhängig von dem grundsätzlichen Aufbau von Beziehungen habe ich erhebliche Zweifel am Aufbau der Tabellen bzw. der angelegten Tabellenstruktur. Kann allerdings keine Empfehlungen dazu geben, da ich die Aufgabe der DB und die Bedeutung verschiedener Tabellen nicht kenne.
Es wäre also vorteilhaft, wenn Du Dir die Mühe machen würdest und die Zusammenhänge mal ausführlich beschreibst.
Ach und Bilder und Logos in der DB zu speichern ist keine gute Idee. Access ist dazu nicht geeignet. Die DB wird bereits mit wenigen Bildern riesengroß. Besser ist es nur einen Pfad und/oder Dateinamen in einem Feld zu speichern und die Bilder und Logos mit einem normalen (installierten) Bildbetrachter per Doppelklick im Textfeld anzusehen.