Hallo,
ich stehe derzeit vor einem kleinen Rätsel bezüglich dem Anfügen von Datensätzen aus anderen Datenbanken in ein zentralen Datenbank und den Auswirkungen des Anfügens auf den Primärschlüssel.
Eine möglichst kurze Problembeschreibung:
In einem Unternehmen gibt es eine Filiale und eine Zentrale.
Eine Aufgabe der Filiale ist es, "Field Trips" zu unternehmen und Informationen über die unterschiedlichen Dörfer zu sammeln.
Die Dörfer stellen im Zielland allerdings die kleinste organisatorische Einheit dar. Darüber gibt es noch so genannte "Wards", "Districts" und "Regions".
Da die Dorfnamen häufiger gleich sind, kommt der Dorfname nicht als Primärschlüssel infrage. Soweit habe ich in der Tabelle "VillagesT" dann einen AutoWert als Primärschlüssel zugewiesen. In dieser Tabelle ist auch das "Ward" gespeichert, in dem das Dorf liegt (ebenfalls AutoWert aus der Tabelle "WardT").
Das "Ward" wiederum wird mit einem District, in dem es liegt, gespeichert (auch hier wieder AutoWert aus der Tabelle "DistrictT"). Und der DIstrict ist ebenso als Datensatz mit der Region (ebenfalls über AutoWert aus der Tabelle "RegionT" gespeichert.
Das bisherige Vorgehen war:
Das Team fährt hinaus, sammelt die Informationen und sendet diese an die Zentrale. Diese gibt die Informationen normal in die Datenbank ein. Dies funktioniert einwandfrei.
Nun besteht die Überlegung, diese Aufgabe an die Filiale abzugeben, das spart Zeit und am Ende verwendet vor allem die Filiale diese Daten, um einen Überblick über ihren zu verantwortenden Bereich zu bekommen (welche Villages gibt es in diesem Ward etc?).
Deswegen haben wir eine Datenbank für die Filiale erstellt, die genau dieselben Tabellen und Formulare wie die der Zentrale enthält. Die entsprechenden Tabellen und Formulare wurden einfach in die neue Filial-Datenbank exportiert.
Stand jetzt haben also die Filiale und die Filial-Datenbank exakt dieselbe Datengrundlage.
Nun gibt es unterschiedliche Wege zum Anfügen der Daten und ich habe soweit wohl die blödeste genommen. Ich habe einfach händisch aus der Tabelle "VillagesT" aus der Filial-Datenbank die neuen Datensätze kopiert und in der Tabelle "VillagesT" in der Zentral-Datenbank ans Ende angefügt.
An sich möchten wir gerne den Filialen mehr Eigenverantwortung geben, sodass sich an der Lösung mit der "Teil-Datenbank" für die Filiale nichts ändern soll.
Mir kam nun aber die Frage, was passiert, wenn wir eine neue Filiale eröffnen.
In der Datenbank der Filiale 1 würde ich dann wieder Datensätze aus "VillagesT" kopieren und in "VillagesT" in der Zentral-Datenbank kopieren. Dann würde ich beispielsweise die VillageID's (Primärschlüssel) 67,68,69 bekommen, wenn ich drei neue Villages hinzufüge.
Wenn aber auch drei Datensätze in "VillagesT" in der Datenbank der Filiale 2 hinzugekommen sind und ich diese in "VillagesT" der Zentraldatenbank anfügen möchte, würden das dann auch Villages 67,68,69 als Primärschlüssel sein.
Dieselben Probleme gibt es dann analog bei "WardT", "DistrictT" und "RegionT".
Ich habe jetzt schon ein bisschen im Netz gegoogelt und bin dabei auf unterschiedliche Möglichkeiten gestoßen, die in die richtige Richtung gehen. Mir scheint die Idee mit Anfügeabfragen am meisten Sinn zu machen, aber mir fehlt noch ein wenig das Verständnis für die Auswirkungen auf den Primärschlüssel und wie ich es schaffe, dass in allen Datenbanken die gleichen Primärschlüssel vergeben werden bzw. es da einfach zu keinen Überschneidungen kommt und das das gleiche Dorf in der Filial-Datenbank nicht den Primärschlüssel 68 hat, aber in der Zentraldatenbank 73 beispielsweise.
Für mich stellt sich erstmal grundlegend die Frage:
Ist eine Lösung prinzipiell erstmal mit begrenzten Access-Kenntnissen möglich, oder wird das zu kompliziert für den Laien?
Hallo Paul,
Wenn du mehr als eine Filiale hast, brauchst Du eh eine Tabelle dafür.
Deren ID/PK kommt dann als FK in die VillageT. Aus dem vorhandenen
Autowert und diesem Fremdschlüssel machst Du dann den PK als Mehr-
felder-Schlüssel.
Würde mir jetzt so auf die Schnelle einfallen.
gruss ekkehard
Hi Ekkehard,
danke für die schnelle Antwort.
Heißt: Du würdest jeweils unterschiedliche individuelle Tabellen in den Filial-Datenbanken haben, die jeweils nur ihre Regionen/Districts/Wards/Villages abspeichern?
Ich füge dann alle neuen Datensätze von allen Village-Tabellen in meine "VillageT" aus der Zentraldatenbank an. Dabei bekommen sie einen neuen PK, aber sie übernehmen den PK, der ihnen bei der Eingabe in die Filial-Datenbank gegeben wurde als FK.
Das führt dann dazu, dass die FK's bei manchen Dörfern teilweise gleich sind, aber das macht ja nichts.
Ich frage mich viel mehr, was dann mit dem "Ward" passiert. Dieser wird ja in dem Village-Datensatz mit gespeichert.
Village 1 hätte als WardID dann 14 (aus Filiale 1)
Village 2 hätte als WardID dann eventuell auch 14 (aus Filiale 2).
Das heißt, sie hätten als Ward dann den gleichen, was ja nicht stimmt, weil die Dörfer in zwei unterschiedlichen Regionen/Filialen liegen.
Heißt, ich müsste obiges Prinzip auch bei den höheren Ebenen anwenden.
1. Anfügen der Regionen
2. Anfügen der Districte
3. Anfügen der Wards
4. Anfügen der Villages.
Das heißt, auch bei den Wards hätte ich dann einen PK bei Anfügen in meine "WardT" Tabelle in der Zentral-Datenbank, als FK nehme ich den PK aus der Filial-Datenbank.
Wenn ich nun die Village-Datensätze hinzufüge, steht doch aber immer noch die WardID im Datensatz, der von der Filial-Datenbank zugeordnet wurde.
Wie kann ich es hinbekommen, dass stattdessen mein neuer PK, den ich dem Ward bei Anfügen in meine Tabelle, gegeben habe, im Village-Datensatz übernommen wird statt dem alten PK durch die Filial-Datenbank.
Ich hoffe du verstehst meine Bedenken. Wahrscheinlich habe ich es lediglich noch nicht so ganz kapiert und stehe noch auf dem Schlauch...?!
Wäre dir sehr dankbar für ein paar weitere Worte!
Hallo Paul,
Wenn ich jetzt so darüber nachdenke, denke ich, dass dein Tabellenaufbau
nicht korrekt ist. Sollte eher wie auf dem angehängten Bild aussehen.
Bin aber (noch) nicht sicher, ob das so schon richtig ist, und zur Lösung
deines Problems beuträgt. Bin etwas unter Druck heute. Schau's mir über's
WE noch mal an. Ausser einer der Cracks ist schneller und/oder weiß es
besser.
Auf jeden Fall müsstest Du so aber auch die Zentrale als eine "Filiale" anlegen.
gruss ekkehard
Hi Ekkehard
danke für deinen Vorschlag.
Ok, ich versuche mich am Wochenende daran. Ich muss noch die FK hinzufügen.
Ich habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.
Heißt:
Region 1 ist auch gleich der Name der Filiale 1.
Region 2 ist auch gleich der Name der Filiale 2.
Wir bauen Filialen nach Regionen auf.
Das Headquarter selbst soll eigentlich NIE eigenständig Dörfer hinzufügen. Es soll lediglich die Datensätze der anderen Filialen zusammenführen.
Ja, kein Stress. Es eilt nicht zu sehr und würde mich jederzeit über ein paar mehr Gedanken freuen.
Hallo Paul,
ZitatIch habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.
O.K., dann kann die Tabelle "Filialen" und der FK in "Regions" entfallen.
D.h. aber auch, das die Filialen keine Regions anlegen können/dürfen,
- oder?
Zitatsoll eigentlich NIE
"eigentlich" und "NIE" ergeben für mich eine
nicht leere Schnittmenge
(kann man das so ausdrücken?).
Da musst du dich entscheiden. Bei "eigentlich" musst du auch die Zentrale
als "Region/Filiale" einrichten.
Ansonsten, wie gesagt, mach ich mir über's WE noch ein paar Gedanken.
gruss ekkehard
Hi Ekkehard,
siehe auch PN.
Zitat
ZitatIch habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.
O.K., dann kann die Tabelle "Filialen" und der FK in "Regions" entfallen.
D.h. aber auch, das die Filialen keine Regions anlegen können/dürfen,
- oder?
Ja, für den Testfall habe ich es aber jetzt so wie du gemacht. 2x Filial-Datenbanken, 1x Zentral-Datenbank. Und jeweils eben so wie du es vorgeschlagen hast. Sagen wir zu Testzwecken, dass Filialen ungleich Regionen sind und eine Filiale mehrere Regionen vereinen kann.
Zitat
Zitatsoll eigentlich NIE
"eigentlich" und "NIE" ergeben für mich eine nicht leere Schnittmenge
(kann man das so ausdrücken?).
Da musst du dich entscheiden. Bei "eigentlich" musst du auch die Zentrale
als "Region/Filiale" einrichten.
Dann nie. Das soll Aufgabe der Branch sein.
Hallo,
anbei mal meine Probe-Datenbanken.
Ich habe 2 Filialen angelegt und eine Zentraldatenbank. Mit entsprechendem Tabellenaufbau.
Die beiden Filial-Datenbanken haben auch Testdaten.
Ich habe in den Filial-Datenbanken schon Append-Queries angelegt, die die Daten in die entsprechenden Tabellen des Zentraldatenbank kopieren (jetzt dürfte die Verknüpfung nicht mehr passen...).
Dies hat anfangs auch super geklappt.
Dann wollte ich noch etwas ausprobieren und habe die Datensätze aus der Zentral-Datenbank gelöscht. Anschließend wollte ich die Datensätze aus den Filialen nochmals in die Zentraldatenbank einpflegen mit den Append-Queries. Nun habe ich aber Schlüssel-Verletzungen und ich weiß nicht so recht, warum.
Außerdem stellt sich mir die Frage, wie das Ganze beim Anlegen von Kunden in den Zentral-Datenbank funktionieren kann.
Da möchte ich ja im Formular "SA_Customer" die Filiale, Region, District, Ward und Village hinzufügen.
Die Listenfelder und deren Aktualisierung klappen da aber leider noch nicht wirklich und ich stelle mir das Ganze schwierig vor, weil die Regionen, Districts, Wards und Villages die PK's aus den Filial-Datenbanken, aus denen ich die Daten in die Zentral-Datenbank kopiere, ja übernehmen. Aber die sind ja teilweise gleich mit den PK's aus der anderen Filial-Datenbank.
Ich würde mich sehr über ein paar Anregungen freuen wie ich dieses Dilemma lösen kann und beim Anlegen des Kunden durch die entsprechenden Listenfelder durchklicken kann unddie entsprechenden Villages, die zu dem ausgewählten Ward gehören etc. richtig zugeordnet werden.
Hallo,
Lösungsweg:
http://www.ms-office-forum.net/forum/showthread.php?p=1633105#post1633105
und etwa hier:
http://dbwiki.net/images/8/81/AccSampleDivideTable.zip
Hallo Paul,
Sorry, komme nicht vorwärts (unerwarteter Besuch).
Folgendes habe ich bis jetzt machen können.
1. Aufgrund deiner Testdaten ergibt es sich, dass es zu einem Branch
mehrere Regions gibt. Das war aus deiner Beschreibung nicht ersichtlich.
Deshalb habe ich da jetzt eine Zwischentabelle eingefügt. Diese brauchst
du in den Branches-DBs nicht. Ebenso die Tabelle "MI_BranchesT". Dafür
wird in "MI_Regions" das Feld "BranchID_FK" mit einem Standardwert
(ID des Branch) belegt.
2. In MI_RegionsT habe ich einen eindeutigen Mehrfelderschlüssel über
"RegionID_Branch" und "BranchID_FK" gelegt. Damit funzt der Import
der Regions-Tabelle(n) aus den Branches schon mal ohne Probleme.
3. Habe ich die relevanten Tabelle aus den Branch_DBs in die Zentrale-DB
importiert (...B1 und ...B2), und diese als .mdb hier angehängt.
Da können die anderen Regulars auch mal drüber schauen.
ZitatNun habe ich aber Schlüssel-Verletzungen und ich weiß nicht so recht, warum.
Wie gesagt, mit "Regions" klappt es (s.o.). Bei den untergeordneten
Tabelle fehlt der, beim Import neu angelegte PK in MI_RegionsT.
D.h., das deren Import nicht mit einer einfachen Anfügeabfrage, wie
bei Regions funktioniert. Jedenfalls nicht ohne einen Bezug auf diesen
neuen Schlüssel. Wird wahrscheinlich über einen Formularbezug zu
lösen sein.
Ich habe mich auch schon gefragt, wie Du den Import überhaupt
vor hast. Lässt du dir Kopien der DBs schicken?
Ich würde da eher eine Schnittstelle per .csv-Dateien bevorzugen.
ZitatAußerdem stellt sich mir die Frage, wie das Ganze beim Anlegen von Kunden in den Zentral-Datenbank funktionieren kann.
Das lösen wir, wenn der Import steht.
guten Abend
ekkehard
P.S. Anmerkung zur angehängten .mdb:
Die Tabellen mit B1 bzw. B2 am Namensende sind normal externe Tabellen.
Im Beziehungsfenster ist oben das Modell der Zentrale abgebildet. Der
untere Teil wäre in den Branches anzuwenden.
Hallo Ekkehard,
ZitatSorry, komme nicht vorwärts (unerwarteter Besuch).
Folgendes habe ich bis jetzt machen können.
Kein Grund sich zu entschuldigen. Eher ganz großen Dank dass du dir trotz dessen so viel Zeit für das Problem nimmst. :)
Zitat1. Aufgrund deiner Testdaten ergibt es sich, dass es zu einem Branch
mehrere Regions gibt. Das war aus deiner Beschreibung nicht ersichtlich.
Deshalb habe ich da jetzt eine Zwischentabelle eingefügt. Diese brauchst
du in den Branches-DBs nicht. Ebenso die Tabelle "MI_BranchesT". Dafür
wird in "MI_Regions" das Feld "BranchID_FK" mit einem Standardwert
(ID des Branch) belegt.
Ja, ich hatte jetzt erstmal exakt den ersten Aufbau von dir übernommen. Das müsste ich auch nochmal erfragen, ob es sein kann, dass einer Branch mehrere Regionen zugeordnet werden. Aber ich denke eher nicht. Wir können es aber gerne jetzt so mal durchspielen, die Systematik bleibt ja gleich.
Zitat2. In MI_RegionsT habe ich einen eindeutigen Mehrfelderschlüssel über
"RegionID_Branch" und "BranchID_FK" gelegt. Damit funzt der Import
der Regions-Tabelle(n) aus den Branches schon mal ohne Probleme.
Ah ja. Das heißt du transferierst die Daten aus den Tabellen der Branches mittels Anfügeabfrage (?) in die Zentral-Datenbank (B1, B2 Tabellen?). Durch diesen Mehrfelderschlüssel ist dann quasi klar, welche Region zu welcher Branch gehört, auch wenn sie den selben FK (durch Import aus den Branch-Datenbanken) haben, richtig?
ZitatIch habe mich auch schon gefragt, wie Du den Import überhaupt
vor hast. Lässt du dir Kopien der DBs schicken?
Ich würde da eher eine Schnittstelle per .csv-Dateien bevorzugen.
Ja, also die Branch soll jeden Tag die Datenbank aktuell halten. Einmal am Tag gehe ich dann in die Datenbank der Branch (wird an zentraler Stelle Dropbox/GoogleDrive gespeichert), weil ich dort die eingetragenen Ausgaben/Einnahmen in das Book-Keeping eintragen muss. Bei dieser Gelegenheit wäre es auch ein einfaches, die entsprechenden Anfüge-Abfragen auszuführen. So dachte ich mir das. Aber liegt wohl auch eher an meinem begrenzten Wissen. Wenn CSV sinnvoller ist, dann ist das natürlich besser. Es soll eben so einfach wie möglich bleiben und da erschien mir eine einfache Abfügeabfrage relativ einfach.
Also die Branch füllt nur entsprechenden Formulare aus und den Rest macht dann die Zentrale (Import in Zentraldatenbank).
Die ganzen gespeicherten Daten werden in der Zentraldatenbank eh nicht zu sehr gebraucht. Wir bräuchten sie dann eben nur um dem Kunden ein Dorf zuweisen zu können und später zu sehen, welche Aktivitäten unternommen wurden.
ZitatWird wahrscheinlich über einen Formularbezug zu
lösen sein.
Ähm ja. Würde mich freuen, wenn du mir das erklären könntest. Denn ich würde es auch ganz gerne verstehen, damit ich es später selbst anwenden kann
Auf jeden Fall noch mal ein riesiges Dankeschön!
Hallo Paul,
ZitatJa, ich hatte jetzt erstmal exakt den ersten Aufbau von dir übernommen. Das müsste ich auch nochmal erfragen, ob es sein kann, dass einer Branch mehrere Regionen zugeordnet werden. Aber ich denke eher nicht. Wir können es aber gerne jetzt so mal durchspielen, die Systematik bleibt ja gleich.
Ja, sorry, das mit der Zwischentabelle ist natürlich Quatsch. Weiss auch
nicht, wie ich darauf gekommen bin. Ich denke nicht, dass es Regions
mit mehreren Branches gibt.
Der Aufbau müsste demnach so sein:
Branches -> Regions -> Districts -> usw.
ZitatAh ja. Das heißt du transferierst die Daten aus den Tabellen der Branches mittels Anfügeabfrage (?) in die Zentral-Datenbank (B1, B2 Tabellen?). Durch diesen Mehrfelderschlüssel ist dann quasi klar, welche Region zu welcher Branch gehört, auch wenn sie den selben FK (durch Import aus den Branch-Datenbanken) haben, richtig?
Ja, richtig erkannt. Und in weiteren untergeordneten Tabellen (Districts,
Wards und Villages) muss auch noch so ein Schlüssel rein, - jeweils über
das Feld ...ID_Branch und den FK der übergeordneten Tabelle.
Beispiel: in Tabelle Districts über die Felder DistrictID_Branch und DistrictID_FK.
Anbei die DB mit den Abfragen zum Import (puh, mann, hab ich ganz
schön dran geknobelt). Diese musst du noch in soweit anpassen, das es
mit den externen Tabellen klappt (habe ich nicht getestet).
Zitatwird an zentraler Stelle Dropbox/GoogleDrive gespeichert
Funktioniert das wie ein normales Laufwerk? Kenne mich damit nicht aus.
Wenn dem so ist, brauchst du doch gar keine getrennten DBs (Backends).
Oder lassen sich daraus die Tabellen nicht verknüpfen?
Dein Kunden-Formular habe ich auch mal geändert. Aus den Listfeldern
habe ich (abhängige) Kombis gemacht. Diese musst du bezüglich der
Anzeige (Namen) noch anpassen (Spaltenbreiten). Normal zeigt man die
ID (1. Spalte) nicht an (Breite = 0cm).
Und wenn du dir die Datensatzherkunft der Kombis anschaust, erkennst
du auch, was ein Formularbezug ist.
gruss ekkehard
Hi Ekkehard,
vielen Dank!
ZitatJa, richtig erkannt. Und in weiteren untergeordneten Tabellen (Districts,
Wards und Villages) muss auch noch so ein Schlüssel rein, - jeweils über
das Feld ...ID_Branch und den FK der übergeordneten Tabelle.
Beispiel: in Tabelle Districts über die Felder DistrictID_Branch und DistrictID_FK.
Ich habe es mal so gemacht, wie ich es verstanden habe. Siehe Screenshot. Passen die Beziehungen so?
ZitatJa, sorry, das mit der Zwischentabelle ist natürlich Quatsch. Weiss auch
nicht, wie ich darauf gekommen bin. Ich denke nicht, dass es Regions
mit mehreren Branches gibt.
Der Aufbau müsste demnach so sein:
Branches -> Regions -> Districts -> usw.
Ok, Rolle rückwärts. Es ist nach Rückfrage nun doch möglich, dass eine Branch mehrere Regionen verwaltet. Von daher passt es also so. Sorry für die Verwirrung.
ZitatFunktioniert das wie ein normales Laufwerk? Kenne mich damit nicht aus.
Wenn dem so ist, brauchst du doch gar keine getrennten DBs (Backends).
Oder lassen sich daraus die Tabellen nicht verknüpfen?
Ja, an sich schon. Ich habe einen Dropbox-Ordner für jede einzelne Branch. Die Branch legt dann ihre Reporting-Dateien in dem Dropbox-Ordner ab. Dort ist auch die Datenbank der Branch gespeichert, die sie laufend aktualisieren.
Die Zentraldatenbank liegt allerdings nicht in der Dropbox (und folglich auch nicht im selben Ordner), sondern an anderer Stelle auf dem Laufwerk.
Würde eine Verknüpfung dennoch funktionieren?
ZitatDein Kunden-Formular habe ich auch mal geändert. Aus den Listfeldern
habe ich (abhängige) Kombis gemacht. Diese musst du bezüglich der
Anzeige (Namen) noch anpassen (Spaltenbreiten). Normal zeigt man die
ID (1. Spalte) nicht an (Breite = 0cm).
Und wenn du dir die Datensatzherkunft der Kombis anschaust, erkennst
du auch, was ein Formularbezug ist.
ZitatAnbei die DB mit den Abfragen zum Import (puh, mann, hab ich ganz
schön dran geknobelt). Diese musst du noch in soweit anpassen, das es
mit den externen Tabellen klappt (habe ich nicht getestet).
Schau ich mir gleich an. Danke auf jeden Fall! :)
Hallo Paul,
ZitatEs ist nach Rückfrage nun doch möglich, dass eine Branch mehrere Regionen verwaltet.
So ist es ja jetzt; - 1 Branch zu n Regions.
Die Zwischentabelle bräuchte man nur, wenn 1 Region durch n Branches
bearbeitet werden würden.
ZitatSiehe Screenshot
Finde ich nicht.
ZitatDie Zentraldatenbank liegt allerdings nicht in der Dropbox (und folglich auch nicht im selben Ordner), sondern an anderer Stelle auf dem Laufwerk.
Würde eine Verknüpfung dennoch funktionieren?
Scheinbar nicht. Ich habe hier:
http://www.hitechcoach.com/index.php?option=com_content&view=article&id=33:remote-access-for-an-access-application&catid=52:remote-access (http://www.hitechcoach.com/index.php?option=com_content&view=article&id=33:remote-access-for-an-access-application&catid=52:remote-access)
dies gefunden:
ZitatIf you place the back end on a web server, unfortunately you can not link to the tables from an Access front end over the internet.
Alternativen (Terminal-Server, (My)SQL-Server, u.ä.) werden dort auch aufgezeigt.
Wobei ich sagen muss, das deine Anwedung, wenn da richtig viele Branches
dazu kommen, förmlich nach einem SQL-Server schreit. Leider kann ich dir dabei
aber nicht behilflich sein.
gruss ekkehard
Hi Ekkehard,
ja sorry, Anhang vergessen. ::)
Jetzt aber...
Ja, im Moment bleibt es erstmal bei 2-3 Branches. Sofern dann ein größeres Investment folgt, wird das Ganze auch professioneller ablaufen und neu aufgesetzt... ;)
Hallo Paul,
NEIN. Die Zwischentabellen gehören ALLE weg.
Denn, wie bereits geklärt wird eine Region NICHT durch MEHRERE
Branches verwaltet.
Ebenso kann ein District nicht in mehreren Regions liegen, usw.
Wenn du das mit den Mehrfelder-Indizes nicht verstanden hast, öffne
die Tabellen in der DB, die ich als letztes angehängt hatte, in der
Entwurfsansicht und schau dir die Indizes an.
gruss ekkehard
Hallo Ekkehard,
ah, alles klar. Ok.
Du hattest in der MI_Regions Tabelle ja diesen Mehrfeldschlüssel benutzt.
Als Indexname hast du "RegionBranch" gewählt. Das hat aber nichts mit der ehemaligen Zwischentabelle "BranchToRegion" zu tun?
Dann würde ich jetzt solche Mehrfeldschlüssel auch in die Tabellen District, Wards und Villages einfügen.
Hallo Paul,
ZitatAls Indexname hast du "RegionBranch" gewählt. Das hat aber nichts mit der ehemaligen Zwischentabelle "BranchToRegion" zu tun?
Ja, das hat mit der Tabelle nichts zu tun; - 'tschuldigung für diese Idee
und die daraus entstandene Verwirrung. Ich bennene die halt nur auch so
ähnlich.
gruss ekkehard
Hi Ekkehard,
alles gut, kein Problem. :)
Ich habe jetzt die Mehrfeldschlüssel hinzugefügt und auch die Anfügeabfragen in der Zentraldatenbank um die Daten aus den "Externen Tabellen" (B1...B2) in die MI_Regions/District/Ward/Village- Tabelle der Zentrale zu übertragen.
Das klappt zwar ohne Schlüsselverletzung, aber da ist noch ein Fehler drinnen.
Beispiel Districts: Einzelne Districts werden mehreren Regionen zugeordnet. Siehe Screenshot und Districts "TestDistrictMOR", "Daressalaam Rural", "Daressalaam Urban", "Makongo", "TestdistrictDar2".
Habe ich einen Fehler bei der Verschlüsselung (siehe Screenshot) oder bei der Anfügeabfrage gemacht (siehe Screenshot 2).
Hallo Paul,
Fehler gefunden.
Es gibt ja nur ein einziges eindeutiges Merkmal, und das ist die BranchID.
Deshalb muss in alle Abfragen ein Filter darauf rein. D.h. aber auch, dass
die Abfragen unter der Region immer den ganzen Beziehungsbaum zu den
übergeordneten Tabelle benötigt. Schau's dir an.
Bei dem ganzen Drübernachdenken und Basteln ist mit zudem noch die
Idee gekommen, statt die Daten aus den einzelnen Branches-DBs in die
T-DB zu schieben (musst du sie ja alle nacheinander öffenen), wäre es doch
besser den Import aus der Zentrale zu bewerkstelligen. Dazu müsste nur
der Pfad zur Branch-DB in die Tabelle MI_BranchesT angelegt sein.
Ich setze mich da jetzt mal dran, und knobel das auch noch aus.
gruss ekkehard
Hallo Paul,
Eh voila.
Anbei neue DB.
Da wird der Import jetzt komplett über ein Formular in der Zentrale-DB
angestossen.
Per Kombi oder Listfeld (kannst du dir aussuchen) werden die Branch(es)
ausgewählt und per Buttonklick importiert. Die benötigten Abfragen
werden dabei vollständig per VBA generiert.
Wichtig:
1. In "MI_BranchesT" muss das Feld für den Pfad zur Branches-DB
eingefügt werden (im Beispiel natürlich schon drin, musst nur die ein-
getragenen Pfade anpassen).
2. Die Tabellen müssen in allen Branch-DBs gleich benamst sein.
3. In "MI_Regions" der Branches musst du sicherstellen, dass das Feld
"BranchID_FK" per Standardwert mit der ID aus "MI_RegionsT" belegt
wird.
So, hoffe nicht wieder was vergessen zu haben.
Hat Spass gemacht; - viel gelernt.
gruss ekkehard
P.S. @regulars
Im Anhang ist jetzt auch wieder ein .mdb dabei, nebst der , auf die rele-
vanten Tabellen reduzierten, Branches(Filialen)-DBs. Falls ihr es euch
anschauen wollt.
Hi Ekkehard,
ich komme leider nicht vor nächster Woche Donnerstag dazu, es auszuprobieren.
Aber ich bin mir sicher, dass ich das schon hinbekommen werde.
Ganz lieben Dank für all deine Bemühungen!
Gruß
Zitat von: Beaker s.a. am Juni 01, 2016, 16:39:26
Hallo Paul,
Fehler gefunden.
Es gibt ja nur ein einziges eindeutiges Merkmal, und das ist die BranchID.
Deshalb muss in alle Abfragen ein Filter darauf rein. D.h. aber auch, dass
die Abfragen unter der Region immer den ganzen Beziehungsbaum zu den
übergeordneten Tabelle benötigt. Schau's dir an.
Hi Ekkehard,
ich habe jetzt mal drübergeschaut.
Jetzt klappt das mit dem Import der Daten super.
Der Mehrfeldschlüssel bleibt trotz neuer Abfragestruktur allerdings bestehen, nicht wahr?
Das Gleiche wollte ich jetzt bei MI_Contacts machen.
Ich habe zwei Tabellen in der Zentraldatenbank angelegt, wo die Kontakte aus den einzelnen Branches reinkommen (B1...B2).
Der Import der Daten in diese beiden Tabellen aus den Branches in die Zentraldatenbank funktioniert ohne Probleme.
Allerdings dann das Anfügen aus diesen beiden Tabellen in die die Tabelle MI_ContactsT nicht.
Schlüsselverletzungen ist wieder das Stichwort.
Ich habe sowohl die Tabellenstruktur von MI_ContactsT als auch die Abfragestruktur der Anfügeabfrage aks Screenshot angehangen. Eigentlich ist doch alles genau gleich zu vorher. Warum also wieder Schlüsselverletzung? Komisch...
Wenn das soweit funktioniert würde ich mir dann die Formular-Lösung anschauen.
Hallo Paul,
ZitatDer Mehrfeldschlüssel bleibt trotz neuer Abfragestruktur allerdings bestehen, nicht wahr?
Ja, die sind wichtig. In der Grafik ist leider nicht zu sehen, ob der
eindeutig ist, da der Fokus auf dem PK liegt; - überprüfen!
ZitatWarum also wieder Schlüsselverletzung?
Weil du den falschen Schlüssel einfügst.
In der 2. Spalte musst du das Feld "VillageID" aus "MI_ContactsT" anfügen,
nicht den Fremdschlüssel aus "MI_ContactsB2".
ZitatWenn das soweit funktioniert würde ich mir dann die Formular-Lösung anschauen.
Ja mach mal. Da werden die Abfragen per VBA generiert, und eine nach
der anderen automatisch ausgeführt. Das hat den Vorteil, dass du
1. nicht für jeden Branch ein halbes Dutzend Abfragen anlegen, und
2. (vor allem) nicht jede Abfrage einzeln öffnen musst. Das ist doch bei
nur zwei Branches schon nervig genug.
gruss ekkehard
Hi Ekkehard,
ahhh ja, Fehler gefunden. Ja, alles klar, das macht auch Sinn. Jetzt funktioniert es reibungslos! Ganz vielen Dank!
Ja mach mal. Da werden die Abfragen per VBA generiert, und eine nach
der anderen automatisch ausgeführt. Das hat den Vorteil, dass du
1. nicht für jeden Branch ein halbes Dutzend Abfragen anlegen, und
2. (vor allem) nicht jede Abfrage einzeln öffnen musst. Das ist doch bei
nur zwei Branches schon nervig genug.
Ja, ich werde mir mal den Code anschauen. Ganz vielen Dank für all deine Mühen nochmal!
Eine Frage dazu noch: Müssen die Dateien zwangsläufig auf einem lokalen Laufwerk sein, oder ist der Pfad auch ok, wenn er zu einem Dropbox-Ordner führt?
Hallo Paul,
ZitatEine Frage dazu noch: Müssen die Dateien zwangsläufig auf einem lokalen Laufwerk sein, oder ist der Pfad auch ok, wenn er zu einem Dropbox-Ordner führt?
Wie gesagt, Dropbox?
Probiers aus.
gruss ekkehard