Import von Datensätzen aus einer anderen DB, aber per VBA

[Nicolo#22]

Hallo Experten,
heute wollte ich folgende Idee verwirklichen: Leider zu wenig Kenntnisse.
Evtl. geht das ja auch so ohne Spezialwissen überhaupt nicht.
Ich habe u.a. eine sehr umfangreiche DB mit all möglichen Daten und Schnickschnack.
Darin sind natürlich auch Tabellen usw.
Jetzt wollte ich eine Mini Version erzeugen, mit nur bestimmten Daten (Tabellen/Formularen etc.
Dazu habe ich die relevanten Daten (Tablellen etc) in eine neue DB importiert.
Alles funktioniert gut. Sogar die VBA Codes.
Jetzt das Problem, Denkfehler.-
Wenn ich in die große DB Daten einfüge, sie pflege, dann sind diese ja nur dort und nicht in der Mini DB.
Wie man jetzt die Daten in der Mini DB aktualisieren kann, per Hand, über Datenimport Externe Daten ist klar, das geht. Aber mühselig.
Was wäre eine schnelle Variante? Per VBA?
Geht sowas überhaupt?
Oder ist der manuelle Weg die einzige, weil fehlerfreie Möglichkeit?
Der Haken ist ja, es sollen nur jene DS in die MINI importiert werden die in der großen DB hinzugekommen sind.
Im Kern ginge es dabei um 2 Tabellen die sich täglich in der großen DB ändern.
Man kann jetzt fragen, warum diese MINI ? Weil sie stark abgespeckt ist, auf das wesentliche reduziert.
Bin gespannt auf eure Meinung. (Knobbi38) ??
Danke

[PhilS]

Was wäre eine schnelle Variante?
Per VBA?
Geht sowas überhaupt?

Wenn es nur um neue Datensätze geht, ist eine (bzw. mehrere) Anfügeabfrage(n) eine relativ einfache Lösung.

Um das Prinzip zu verdeutlichen:

INSERT INTO LokaleTabelle (PkSpalte, Spalte2, Spalte3)
 SELECT ExterneTabelle.PkSpalte ExterneTabelle.Spalte2, ExterneTabelle.Spalte3
 FROM  ExterneTabelle IN 'C:\Pfad\zur\Anderen.accdb'
 LEFT JOIN LokaleTabelle
  ON LokaleTabelle.PkSpalte = ExterneTabelle.PkSpalte
WHERE LokaleTabelle.PkSpalte IS NULL;

Wenn du das ganze über VBA machst, kannst du auch einen Dateidialog vorschalten und den Pfad zur DB dann per VBA in das SQL-Statement einbauen.

Bin gespannt auf eure Meinung. (Knobbi38) ??

Du kannst andere Benutzer mit einem @ vor dem Benutzernamen taggen: @Knobbi38, dann werden sie auch über deinen Post informiert. Das sollte man allerdings nur tun, wenn man recht sicher ist, dass der Benutzer auch an dem Thema interessiert ist.

[Doming]

Moin Nicolo,

sollen sich denn die Änderungen, die Du in der ,,kleinen" DB durchführst, auch auf die originale DB auswirken?
Dann wären verknüpfte Tabellen das Mittel der Wahl. Dann würdest Du Dir auch das Ex/Importieren von Daten ersparen und somit das Erzeugen von redundanten Daten.
Du brauchst ja nicht allen Schnickschnack der großen DB verwerten, die Daten kannst Du ja durch Abfragen auf das Nötige reduzieren.
Über welche Datenmengen reden wir denn?

Gruß
 Doming

[Knobbi38]

Hallo Nicolo,

ich kann den Sinn einer kleineren Variante deiner Datenbank noch nicht ganz erkennen, denn eigentlich sollten die Tabellen miteinander in Beziehung stehen. In einer ,,Mini-DB" sind dann ja nicht mehr alle Tabellen enthalten. Zudem erhöht sich dadurch der Pflegeaufwand für die Datenbanken. Speicherplatz kann für eine solche Maßnahme kein Grund sein.

Kann es sein, dass die Datenbank nicht in ein Frontend und ein Backend aufgeteilt ist? In diesem Fall wäre es sinnvoll, die DB aufzuteilen und mit zwei verschiedenen Frontends auf ein gemeinsames Backend zuzugreifen. Dann würde sich das Synchronisieren bzw. Replizieren von zwei Datenbanken erübrigen. Sollte die BE dann zu groß werden – oder vielleicht auch schon früher –, könnte man auf einen "richtigen" SQL-Server, möglicherweise in einer kostenlosen Variante, umsteigen. Das halte ich für die sinnvollere Lösung.

Was das Synchronisieren/Replizieren zwischen zwei DBs betrifft, kann man natürlich eine Prozedur in VBA erstellen, welche die entsprechenden "Kopieraktionen" in der richtigen Reihenfolge, wegen der bestehenden Beziehungen, durchführt. Schwierig wird es jedoch, wenn Änderungen in der Mini-DB auf die "Master"-DB zurückgeführt werden sollen. Das kann u.U. wegen der dahinter stehenden Logik sehr kompliziert werden. Ohne Not würde ich von so einem Vorhaben abraten.

Gruß Knobbi38

[Nicolo#22]

@PhilS
Hmm, möglich. Aber mit SQL kenne ich mich zu wenig aus.
@Doming
An verknüpfte Tabellen hab ich auch schon gedacht. Wäre für meinen Zweck ideal.
ABER:
Hab dazu die große u. kleine DB kopiert (Arbeitskopien)
Dann eine neue DB als BackEnd angelegt, in diese habe ich testweise eine der Tabellen importiert.
Damit wären alle DS aus dieser Tabelle im Backend.
Dann habe ich in der großen und kleinen DB die Ur.Tabelle umbenannt und dafür die verknüpfte eingefügt.
Den Tabellennamen beibehalten.
Dann im Beziehungsfenster die Beziehungen neu erstellt.
Aber es kann keine Integrietät erstellt werden, es wird nur eine dünne Linie angezeigt.
Dann in der grossen DB einen DS hinzugefügt.
Es wird aber in der grossen und kleinen DB der neue DS korrekt angezeigt.
Habe jetzt Zweifel ob das so korrekt ist.

[Nicolo#22]

@Knobbi38
Danke siehe #4
Hab vermutlich etwas übersehn.
Der Grund für die MINI ist einfach.
Die Tabellen sind alle gleich. aber bestimmte Formulare haben bestimmte Felder nicht.
Update.
Frage an dich. Wenn die Beziehungen im BE korrekt dargestellt sind, jedoch im den beiden Frontend nur als dünne Linien
ist das so richtig?

[Bitsqueezer]

Hallo,

bei einer Aufteilung in BE und FE gehören natürlich ALLE Tabellen in das BE.

Du kannst keine Beziehung mit RI über Datenbanken hinweg erstellen (also eine Tabelle im FE und eine andere im BE).

Für Access ist das dann nur eine "Abfragevorlage" (die dünne Linie) und wird das bei neuen Abfragen als Verbindung für ein JOIN vorschlagen, aber das sollte man tunlichst vermeiden ("Verseuchung" des Beziehungsfensters mit Dingen, die in Abfragen gehören und nicht in den Beziehungseditor).

Gruß

Christian

[MzKlMu]

Hallo,

aber bestimmte Formulare haben bestimmte Felder nicht.

Dazu braucht es doch keine extra (mini) DB. Mann kann doch aus einer beliebig großen Tabelle nur die Felder auf ein Formular nehmen, die das Formular wirklich braucht.

Aber es kann keine Integrietät erstellt werden,

Dann hast Du grundsätzliche Fehler in den Daten. Es könnte z.B. sein, dass es auf der n-Seite Schlüsselwerte gibt die auf der 1-Seite nicht vorhanden sind. Das muss korrigiert werden, sonst hast Du inkonsistente Daten.

[Nicolo#22]

@MzKlMu
Klaus, ich denke ich hatte einen Fehler drinne. Hab jetzt nochmal alles neu erstellt.
Alles passt jetzt, wg. der Integrität.
Der Fehler lag vermütlich daran (laut Christian) weil ich nicht ALLE Tabellen verknüpft hatte.
Bez. Mini DB. Das ist schon so gewollt. Die Master DB ist sehr umfangreich und kompliziert aufgebaut.
An bestimmten Feldern in FRM sind spezielle Codes geknüpft (von Kobbi38) die aber dann Fehler bringen
wenn ich die Felder in einer neuen FRM Kopie einfach lösche.
Werde jetzt mal überlegen was am meisten Sinn macht.
Danke euch.

[Knobbi38]

Hallo Nicolo,

nur damit keine Missverständnisse auftreten: Beziehungen werden in so einer Konstellation nur in der BE angelegt, nicht im Frontend. Wie Christian schon sagte, sind das im Frontend nur "Abfragevorlagen", welche man eigentlich gar nicht braucht und besser löscht.

An bestimmten Feldern in FRM sind spezielle Codes geknüpft (von Kobbi38) die aber dann Fehler bringen wenn ich die Felder in einer neuen FRM Kopie einfach lösche.

Ja sicher, denn sie sollen ja eine bestimmte Funktionalität implementieren. Gibt es die Felder nicht mehr, stellt sich die Frage, ob man dann überhaupt noch diese Funktionalität gebrauchen kann; wenn nicht, wird der entsprechende Code gelöscht.

Knobbi38

[Nicolo#22]

Beziehungen werden in so einer Konstellation nur in der BE angelegt

Nachfrage:
Als ich die verknüpften Tabellen vom BE in das FE eingefügt habe (da waren ja schon die org. Tabellen drin) dann
musste ich die Beziehungen zu den Ur-Tabellen und diese dann löschen.
Bei den eingefügten verknüpften Tabellen waren die Beziehungen aber sofort richtig vorhanden.
(weil sie aus dem BE übernommen wurden). Richtig?
-
Deine Codes wegen der Funktionen, die sind alle wichtig und in der Master DB nach wie vor unberührt, bin
froh das die alle gut funktionieren.
In der MINI habe ich viele Dinge weggelassen. Bedienung vereinfacht.
Man kann natürlich darüber geteilter Meinung sein, ich weiß.

[Knobbi38]

Die org. Tabellen und dessen Beziehungen sind vorher zu löschen und anschließend werden diese durch die verknüpften Tabellen ersetzt. Wenn eine Beziehung zwischen verknüpften Tabellen im BE besteht, wird das im FE im Beziehungsfenster angezeigt. Will man diese Bearbeiten steht hinter dem Beziehungstyp der Vermerk (extern). So kann man das direkt erkennen. Für einen Überblick oder zum Ausdrucken kann man auch einen Beziehungsbericht erstellen.

Zu den Codes kann ich erstmal nichts sagen, müsste man im konkreten Fall prüfen.

Gruß Knobbi38
 

[Nicolo#22]

Nun, nur für mich jetzt als Info für spätere Recherchen.
Um eine Tabelle zu löschen muss ich zuerst im Beziehungsfenster die Beziehungen löschen, erst dann
lässt sich die Tabelle löschen.
Damit sind auch die Tabellen in den Abfragen weg und werden beim einfügen der verknüpften Tabellen
automatisch wieder eigefügt und die Beziehungen gemäß >BE< (Backend) eingesetzt.
Beim eigentlichen Einfügen der verknüpften Tabellen wird kein Beziehungsfenster angezeigt, nicht automatisch.
Wenn man dies dann manuell öffnet stellt man fest das die Beziehungen zwar alle vorhanden sind aber abgeblendet.
Ein Vermerk >extern< konnte ich nicht entdecken.
Die Codes von denen ich sprach, sind diese die du mir mal eingebaut hast (Master DB). Passt.
OT. Wenn man sowas (BE+FE) veranstaltet mit bestehenden Daten muss man beachten das Access den Ort
der BE und somit den Pfad der Verknüpfung festhält und speichert.
Verschiebt man später das BE gibts Probleme. Über den Tabellen Verknüpfungsmanager
kann man das korrigieren in dem man den neuen Ort der BE angibt.
Wie gesagt, für mich. Die Experten wissen das vorher.