Nachschlage-Assistent in Tabelle

[dobby110]

Hallo zusammen,

ich habe eine Frage bzgl. der Verknüpfung von Tabellen.

Ich habe eine Tabelle mit Dokumenten. In dieser habe ich je ein Feld (über die Nachschlagefunktion) für den Namen des Investments und des Fonds.
Die Tabelle mit den Dokumenten will ich jetzt auslagern und daraus eine eigene "BackEnd-Datei" machen, bzw. das habe ich schon gemacht.

Logischerweise findet er dann in den anderen Tabellen die Verknüpfungen für die Nachschlagefunktion nicht mehr.

Hier mal ein Auszug aus der SQL-Ansicht:

Code: [Auswählen]

[/SELECT Investments.ID, Investments.[Name Ziel-Investment]
FROM Investments INNER JOIN [Investments / Fonds] ON Investments.ID = [Investments / Fonds].[Ziel-Investment];code]


Wie kann ich den Code denn umschreiben, damit die Verknüpfungen wieder funktionieren? Oder anders gefragt. Geht das überhaupt, weil diese Daten in einer anderen BackEnd-Datei stehen?

Diese heißt "Monitoring - BackEnd.accdb"

Die Dokumente speichere ich jetzt in folgender BackEnd-Datei:
"Dokumentenverwaltung - BackEnd.accdb"

Ich müsste also in dem oben genannten Code irgendwie die Information einfließen lassen, dass die Felder in der "Monitoring - BackEnd.accdb" stehen.

Hoffe das war verständlich. :-)

Vorab schon einmal vielen Dank für die Hilfe. Und bitte nicht zu kompliziert antworten. Ich bin nicht so versiert. Also am besten so antworten, als hätte ich überhaupt keine Ahnung ;-)

Danke


[DF6GL]

Hallo,

als hätte ich überhaupt keine Ahnung

weshalb Konjunktiv?   

1) wirf die Nachschlagefelder in den Tabellen heraus. Die haben mit den eigentlichen Beziehungen zunächst gar nichts zu tun.

2) Vermeide DRINGEND Leer-,  Sonderzeichen und reservierte Wörter in Benennungen. ("Investments / Fonds" ist ein NoGo)

3) Das BE darf nur die Tabellen als solche enthalten. Alle anderen Objekte kommen in die Frontend-Datei.

3) Sobald die DB (in BE und FE) aufgeteilt worden ist, müssen die Tabellen aus dem FE gelöscht werden, sofern der Aufteilungsassistent das nicht schon gemacht hat. Anschließend sind die Tabellen aus dem BE wieder neu zu verknüpfen  (Tabellenverknüpfungsmanager).

4) Die Abfrage im FE sollte dann ohne weitere Änderungen funktionieren.

5) Fehlen in der Abfrage Daten aus weiteren Stammtabellen (Nachschlagetabellen) , so sind diese in die Abfrage mit aufzunehmen und über die entspr. Schlüsselfelder zu verknüpfen.

6)  Alles in Allem sollten Bearbeitungen an Daten nur über Formulare erfolgen, nicht direkt an/mit Tabellen oder Abfragen.

[dobby110]

Danke für die Hilfe.

Ich hätte in diesem Zusammenhang noch eine andere Frage.
Die Aufteilung der Datenbank mache ich auf Grund der Dateigröße.
Ich habe jetzt für jeden Fonds eine "eigene" Datenbank mit den dazugehörigen Dokumenten.

Insgesamt sind das jetzt 11 BackEnds, die ich mit der FrontEnd verknüpft habe. Alle sind identisch aufgebaut.

Ist es möglich über eine Abfrage, alle Dokumente wieder in einem Abfrageergebnis zusammenzuführen? Ich überlege mir nämlich gerade wie ich die Navigation aufbaue, wenn ich so viele BackEnd-Dateien im Hintergrund habe. Am schönsten wäre es, wenn ich das Formular wie zuvor auch nutzen kann. Dieses war aber nur mit einer Tabelle verknüpft, in der alle Dokumente zu finden waren.

Vom Aufbau ist es so, dass ich einen Fonds über ein DropDown Menü auswähle. Daraufhin werden mir in einem Unterformular alle Investments zu dem Fonds aufgeführt und darüber gelange ich in die Dokumentenverwaltung zu dem Investment.
Das funktioniert in dieser Form aber nur, wenn die Dokumente alle in EINER Tabelle oder Abfrage zu finden sind.



 

[DF6GL]

Hallo,

es erhebt sich hier zunächst die Frage, warum die BE-Tabellen so groß werden.  Verwendest Du gebundene OLE-Objekte zur Ablage von Dokumenten (welcher Art sind diese?)

Hast Du die die BE-Datei(en) mal komprimiert/repariert?

Auch eine Abfrage kann nicht alle Daten aus allen BEs zusammenführen, wenn die Abfrage nicht mit Kriterien selektiv wirkt. Zudem käme hier nur eine Union-Abfrage zum Zuge.

Zeige mal das Beziehungsfenster einer BE-Datei.

[dobby110]

wir verwalten in der Datenbank alle Dokumente welche für die Investments kommen. Daher ist die Datenbank jetzt an ihrem Limit von 2 GB angekommen und es haben sich keine weiteren Dokumente mehr speichern lassen. Deswegen habe ich die BackEnd vervielfältigt, so dass ich die Dokumentenverwaltung nochmals pro Fonds aufteilen kann. Somit hätte jeder Fonds 2 GB an Volumen zur Verfügung.
Es handelt sich meist um .pdf Dateien, die dort gespeichert werden. Jahresberichte, Monatsberichte und und und

Und das ist jetzt quasi das Problem. Wo ich zuvor eine Tabelle in der Datenbank mit den Dokumenten hatte, da habe ich jetzt 11 Tabellen, welche auf die diversen BackEnds verknüpft sind.

War das verständlich ?

Wäre eine Union Abfrage da keine Lösung?
die BackEnds für die Dokumentenverwaltung sind ja alle gleich, da sie zuvor in einer einzigen Tabelle standen. Jetzt sind es 11 und ich habe in jeder nur die Dokumente für den entsprechenden Fonds drin stehen lassen.

[MzKlMu]

Hallo,
die Union nutzt nix, denn für die Union gilt ja auch die Grenze von 2GB.
Access ist zum direkten Speichern von Dokumenten nicht geeignet.
Das hätte man von vorn herein anders lösen sollen.
Man speichert in der DB nicht das Dokument selbst, sondern nur den Pfad zum Dokument. Ein Doppelklick auf das Feld öffnet dann extern das Dokument zur Ansicht.
Man kann auch ein Bildsteuerlement anlegen und das Bild (bzw. Dokument) beim Anzeigen des Datensatzes direkt zuweisen.
Gerade bei PDF's ist das relativ einfach.

Mit diesem Verfahren wird in einem Backend die Grenze von 2GB eher niemals erreicht werden.

Meiner Meinung nach werdet Ihr um eine Umstrukturierung nicht herumkommen.

In dieser habe ich je ein Feld (über die Nachschlagefunktion)

Und noch mal der Hinweis zum Nachschlageassi.
Vermeide unbedingt solche Felder in den Tabellen. Gerade bei großen DBs sind das Bremsen. Auch werden im Hintergrund Beziehungen angelegt (mit Indizierungen) die man nicht sieht und zu Lasten der Performance geht. Es gibt noch viel mehr Nachteile. Also raus damit.
Die sind nur in Formularen (=Kombinationsfelder) sinnvoll.

[dobby110]

ja das habe ich schon vermutet, dass es wohl nur auf die Art und Weise funktioniert, wie ich es jetzt gelöst habe. Aber das ist natürlich nicht das gelbe vom Ei.

Schafft man es denn irgendwie die Dokumente auszulagern oder müsste man diese einzeln neu extern irgendwo speichern, was bei über 3000 Dokumenten wohl nicht wirklich möglich wäre.

[MzKlMu]

Hallo,

was bei über 3000 Dokumenten wohl nicht wirklich möglich wäre.

warum soll das nicht möglich sein ?
Oder meinst Du das wegen des Aufwandes ?
Speicherplatz ist da kein Problem, das wird auf der Platte weniger beanspruchen als in der DB selbst. Ich glaube nicht, dass die 3000 Dateien mehr als 2GB beanspruchen.

Man müsste nur einen Weg finden um das aus den jetzigen Backends zu automatisieren. Aber da habe ich keine Ahnung wie das gehen könnte.
Aber da gibt es sicher andere User hier die dazu was sagen können.

Und wenn die DB umstrukturiert wird, denke an die Nachschlagefelder.

[DF6GL]

Hallo,

vielleicht hilft dies weiter:
http://www.access-im-unternehmen.de/269 

Und es kommt darauf an, wie die Dateien gespeichert sind.

[steffen0815]

Hallo,

die Union nutzt nix, denn für die Union gilt ja auch die Grenze von 2GB.

Das sehe ich erst mal nicht so.
Der Union sollte egal sein wie groß die BE's sind. Was sicher funktioniert ist eine Union ohne die eigentlichen Dokumente. Das jeweilige Dokument könnte dann per separaten Befehl geholt werden.

@dobby:
Du hast immer noch nicht geschrieben in welcher Form die Dokumente gespeichert sind.
OLE oder Anlage-Feld?

[dobby110]

Es ist ein Anlage-Feld. Über die Büroklammer importiere ich die Dokumente in die Datenbank.

Versuche jetzt gleich mal eine Union Abfrage. Mal sehen was passiert.
Trotzdem wäre es wohl besser, wenn ich die Dokumente auf einem Laufwerk speichere und verknüpfe.
Wenn jemand eine Idee hat, wie ich das am einfachsten anstellen kann, dann wäre ich sehr dankbar.
Manuell 3000 Dokumente in einem Ordner speichern und dann nochmal neu zu "verlinken" ist schon etwas aufwändig.

Zur Ergänzung - Union-Abfrage funktioniert nicht. Das Feld mit den Anlagen wird nicht gezogen oder ich mache etwas falsch.

Habe die Union-Abfrage wie folgt erstellt:

Gut möglich, dass das gar nicht richtig ist

Code: [Auswählen]

SELECT Dokumente_10425.*
FROM Dokumente_10425
UNION
SELECT Dokumente_10428.*
FROM Dokumente_10428
UNION
SELECT Dokumente_10434.*
FROM Dokumente_10434
UNION
SELECT Dokumente_10435.*
FROM Dokumente_10435
UNION
SELECT Dokumente_10425.*
FROM Dokumente_10425
UNION
SELECT Dokumente_10441.*
FROM Dokumente_10441
UNION
SELECT Dokumente_10444.*
FROM Dokumente_10444
UNION
SELECT Dokumente_10445.*
FROM Dokumente_10445
UNION
SELECT Dokumente_10446.*
FROM Dokumente_10446
UNION
SELECT Dokumente_10448.*
FROM Dokumente_10448
UNION SELECT Dokumente_10457.*
FROM Dokumente_10457;



Die ersten Datensätze werden mir noch angezeigt, wenn ich dann runter scrolle, steht in allen Feldern nur noch

#Name?

Wenn ich dann wieder hoch scrolle, steht das auch in den ersten Datensätzen und alle Datensätze sind fehlerhaft

[dobby110]

hier mal ein Screenshot wie es dann aussieht.

[Lachtaube]

Bei einer Web- oder neuerdings Power-App sind Anlagefelder sicherlich hier und da angebracht. Bei einer Desktop-Anwendung wird man wegen bestehender Artefakte (einen davon hast Du ja bereits in der Vereinigungsabfrage erlebt) erher darauf verzichten.

Andererseits würde ich aber auch keine 3000 Dokumente in nur einen Ordner verfrachten, sondern mir eher eine Ordner-Struktur dafür ausdenken (Anfangsbuchstabe(n) des Kunden und/oder des Fonds, ggf. Jahr einbeziehen), um den manuellen Überblick nicht zu verlieren.

PS: für den Re-Export der 3000 Dokumente würde ich mir mit VBA etwas zusammenbasteln, das dann auch gleichzeitig den Speicherort des exportierten Dokuments in ein neues Feld der Tabelle einträgt. Anschließend würde ich das Backend in ein neues Backend (ohne das Anlagefeld) importieren, auf Herz und Nieren prüfen und bei Erfolg das alte Backend in die Tonne werfen.

[Frithjiof]

Hallo  dobby110.

Deine UNION SELECT Abfrage  müsste so bearbeitet werden, dass nur bestimmte Felder zusammengefasst werden.
z.B.
Erstens: das Schlüsselfeld 
Zweitens: ein Bezeichnungsfeld Name oder sowas

Code: [Auswählen]

SELECT Dokumente_10425.idDokument, Dokumente_10425.DokumentName
FROM Dokumente_10425
UNION
SELECT  Dokumente_10428.idDokument, Dokumente_10428.DokumentName
FROM Dokumente_10428
UNION
....

So wird verhindert dass die 3000 PDFs geladen werden müssen.
Über das Schlüsselfeld kann dann gezielt ein PDF wo auch immer her und wo auch immer hin geladen werden.

Was das Platzproblem betrifft: Könnten die PDFs nicht gezippt werden?

Frithjof

[steffen0815]

Hallo,
da es Anlagefelder sind, ist es kein größeres Problem die Daten als Datei auszuschreiben (Field2.SaveToFile Methode).
Du solltest dir allerdings vorher Gedanken machen wie die Daten im Dateisystem strukturiert abgelegt werden sollen.

Btw:
Das Zippen von PDF's bringt im Normalfall nur recht wenig, da eine PDF selbst schon  komprimiert ist.