Access Datenbank Komprimieren

Computer: Software & Programmierung Datenbanken allgemein
#3

Komprimieren klappt jetzt nach Deinem Verfahren. Danke nochmals.

Wäre sicherlich alles viel einfacher, wenn das nicht mein erstes Projekt wäre! Eigentlich hatte ich die Datenbank in Mehrere aufteilen müssen. Dann wäre das Applikationen wechseln nicht nötig. Ist mir nachträglich aber zu viel Aufwand (never touch a running system).

Harald

Du mußt die erste Applikation wirklich
schließen (Docmd.Quit!)
Deshalb kannst Du die 2. App auch nicht
per Run starten, sondern mußt sie per
Shell bzw. ShellExecute ausführen.

Reinhard

#4

Die Trennung in Daten- und Programm-Datenbank sollte man in jedem Falle machen (ist eigentlich nicht besonders aufwändig…). Die Daten-Datenbank kann man dann aus der Programm-Datenbank heraus komprimieren. Die Programm-Datenbank sollte dann nur noch wachsen, wenn man Programmänderungen macht. (Und dann sollte man sie ohnehin kompilieren und komprimieren, bevor man sie den Benutzern zur Verfügung stellt).

Reinhard

#5

Das sagst Du so, ist nicht so aufwendig. Ich habe für mein Programm ein eigenes Menü erstellt. Hierein habe ich unter Anderem aus dem Access-Menü den Punkt Datei/Externe Daten/Importieren hinein kopiert. Damit können meine Kunden Adreßdateien aus den verschiedensten Anwendungen importieren. Wie bekomme ich diese importierten Tabellen in die Daten-Datenbank? Ich habe in dem Dateiauswahlfenster (was sich nach Anklicken des Importieren-Befehls) öffnet keine Möglichkeit gefunden die Zieldatenbank zu bestimmen.

Außerdem müßte ich alle set db = currentdb Anweisungen ändern, um auf die Daten-Datenbank zuzugreifen. Oder?

Gruß
Harald

PS: Mir fällt da noch was ein zum Import von Daten. Wenn ich aus meiner Entwicklungsumgebung das Fenster zum Importieren von Daten öffne, dann wird mir unter Dateityp als oberstes „Microsoft Access (*.mdb;…)“ angeboten. Installiere ich auf dem gleichen Rechner die Anwendung mit dem von mir erstellten Setupprogramm, dann erscheint an der Stelle Registrierfehler (*.*). Das Gleich ist bei anderen Zielrechnern. Hast Du dafür eine Erklärung?

#6

Das sagst Du so, ist nicht so aufwendig.
Ich habe für mein Programm ein eigenes
Menü erstellt. Hierein habe ich unter
Anderem aus dem Access-Menü den Punkt
Datei/Externe Daten/Importieren hinein
kopiert. Damit können meine Kunden
Adreßdateien aus den verschiedensten
Anwendungen importieren. Wie bekomme ich
diese importierten Tabellen in die
Daten-Datenbank?

Du bindest die externen Tabellen in die Frontend-Datenbank ein - dann verhalten sie sich fast genauso wie lokale Tabellen. Das ist übrigens genau das, was der Assistent zur Datenbankaufteilung macht!

Ich habe in dem
Dateiauswahlfenster (was sich nach
Anklicken des Importieren-Befehls) öffnet
keine Möglichkeit gefunden die
Zieldatenbank zu bestimmen.

Brauchst Du dann auch nicht…

Außerdem müßte ich alle set db = currentdb
Anweisungen ändern, um auf die
Daten-Datenbank zuzugreifen. Oder?

Nee, brauchst Du auch nicht. Nur kannst Du Recordsets nicht mehr mit dbOpenTable öffnen, sondern mußt dbOpenDynaset angeben und die Methoden auf Recordsets vom Tabellentyp funktionieren nicht mehr, also im wesentlichen das Seek - mußt Du dann durch FindFirst ersetzen.

Gruß
Harald

PS: Mir fällt da noch was ein zum Import
von Daten. Wenn ich aus meiner
Entwicklungsumgebung das Fenster zum
Importieren von Daten öffne, dann wird mir
unter Dateityp als oberstes „Microsoft
Access (*.mdb;…)“ angeboten. Installiere
ich auf dem gleichen Rechner die Anwendung
mit dem von mir erstellten Setupprogramm,
dann erscheint an der Stelle
Registrierfehler (*.*). Das Gleich ist bei
anderen Zielrechnern. Hast Du dafür eine
Erklärung?

Da wird wohl der Import-Filter nicht richtig installiert.

Reinhard

#7

Du bindest die externen Tabellen in die
Frontend-Datenbank ein - dann verhalten
sie sich fast genauso wie lokale Tabellen.
Das ist übrigens genau das, was der
Assistent zur Datenbankaufteilung macht!

Ich habe in dem
Dateiauswahlfenster (was sich nach
Anklicken des Importieren-Befehls) öffnet
keine Möglichkeit gefunden die
Zieldatenbank zu bestimmen.

Brauchst Du dann auch nicht…

Tut mir leid, aber das kapiere ich nicht. FrontendDB ist doch die ProgrammDB und Backend die DatenDB oder?
Dann öffnen meine Anwender doch die FrontendDB und der Import geht automatisch in diese DB?

Beispiel:
Ich möchte eine Tabelle aus Excel in meine DB importieren! (nicht verknüpfen)!

Harald

#8

Tut mir leid, aber das kapiere ich nicht.
FrontendDB ist doch die ProgrammDB und
Backend die DatenDB oder?
Dann öffnen meine Anwender doch die
FrontendDB und der Import geht automatisch
in diese DB?

Nein, der Import geht (bzw.: sollte gehen) in die verknüpfte Tabelle der Frontend-DB, die Tabelle selbst liegt in der Backend-DB. Das ist doch genau der Sinn der verknüpften Tabellen.

Beispiel:
Ich möchte eine Tabelle aus Excel in meine
DB importieren! (nicht verknüpfen)!

Also: Die Excel-Datei wird in eine verknüpfte Access-Tabelle importiert.

Reinhard

#9

Ich habe eine kleine Testdatenbank (mit 2 Tabellen) mit dem Assentent zur Datenbankaufteilung in FrontendDB und BackendDB aufgeteilt. Dann habe ich die FrontendDB geöffnet und Datei/Externe Daten/Importieren ausgeführt. Ich habe dann eine Tabelle aus einer weiteren Datenbank (die nicht in meiner Testdatenbank existiert) angeklickt und importiert. Leider landet diese dann in der FrontendDB, wo ja nur noch Verknüpfungen auf Tabellen in der BackendDB existieren sollen. Die BackendDB ist vom Import nicht betroffen!

Noch ne Frage bezüglich Typ dynaset. Ist das Suchen in Recordsets von diesem Typ nicht langsamer?

Harald

#10

Ich habe eine kleine Testdatenbank (mit 2
Tabellen) mit dem Assentent zur
Datenbankaufteilung in FrontendDB und
BackendDB aufgeteilt. Dann habe ich die
FrontendDB geöffnet und Datei/Externe
Daten/Importieren ausgeführt. Ich habe
dann eine Tabelle aus einer weiteren
Datenbank (die nicht in meiner
Testdatenbank existiert) angeklickt und
importiert. Leider landet diese dann in
der FrontendDB, wo ja nur noch
Verknüpfungen auf Tabellen in der
BackendDB existieren sollen. Die BackendDB
ist vom Import nicht betroffen!

OK - wir verstehen unter „Import“ wohl etwas unterschiedliches… (Ich verwende dazu normalerweise nicht die Assistenten, da sie in der Laufzeitumgebung nicht funktionieren.)

Importiere halt die Excel-Tabelle in eine temporäre lokale Tabelle und füge diese per Anfügeabfrage (oder besser: per Code - dann kannst Du Fehler flexibler behandeln) an die verknüpfte Tabelle an. Dann mußt Du auch Indizes usw. nicht immer neu zu der Tabelle hinzufügen (wenn Du das überhaupt getan hast…). Danach kannst Du die lokale Tabelle wieder weglöschen.

Bei dieser Prozedur dürfte Deine Frontend-Datenbank fortlaufend anwachsen. Da sie aber ja von Zeit zu Zeit mit Deiner Entwicklungsversion übergemangelt wird, ist das aber unerheblich.

Ich gehe bei meinen Kunden so vor, daß ich ein zentrales Netzwerkverzeichnis einrichte, aus dem bei jedem Rechnerstart eine frische (ggf. von mir aktualisierte) Version der Frontend-DB geholt wird. Damit ist die Frontent-DB immer wieder kompiliert und komprimiert…

Noch ne Frage bezüglich Typ dynaset. Ist
das Suchen in Recordsets von diesem Typ
nicht langsamer?

Findfirst ist langsamer als Seek - aber eigentlich nur graduell. Wichtiger ist, bei der Suche Indizes zu verwenden (was man bei Seek halt zwangsläufig tun muß).
Man sollte eigentlich generell nur Dynasets verwenden - um eingebundene Tabellen benutzen zu können, und um ggf. auf SQL-Server o.ä. migrieren zu können.

Reinhard

#11

OK - wir verstehen unter „Import“ wohl
etwas unterschiedliches… (Ich verwende
dazu normalerweise nicht die Assistenten,
da sie in der Laufzeitumgebung nicht
funktionieren.)

Du hast leider zum Teil recht. Der Importassistent funktioniert in der Runtime-Version nur, wenn irgendein Fenster (Formualar, Tabelle, …) geöffnet ist. Ich habe deshalb immer im Hintergrund ein unsichtbares Formular geöffnet. Außerdem steht in der Liste der zu importierenden Typen „Registrierungfehler (*.*)“ statt „Microsoft Access …“. Klicke ich im Importassistent eine .mdb-Datei an, wird diese aber geöffnet und man kann Tabellen aus Access-Datenbanken importieren.

Der Vorteil des Assistenten ist, man muß kein Byte programmieren, nichts testen, und der Assistent öffnet nach der Dateiauswahl die Excel-Tabelle, Access-Datenbank, … und gibt einem die Möglichkeit eine Tabelle auszuwählen (müßte man sonst auch noch alles programmieren).

Importiere halt die Excel-Tabelle in eine
temporäre lokale Tabelle und füge diese
per Anfügeabfrage (oder besser: per Code -
dann kannst Du Fehler flexibler behandeln)
an die verknüpfte Tabelle an.

Dann dauert der Import bei großen Tabellen leider unnötig lange, da ich die Tabelle immer zweimal anfassen muß.

Eine einfache Lösung für mein Importproblem, ohne viel Programmieraufwand, sehe ich noch nicht.

Bei dieser Prozedur dürfte Deine
Frontend-Datenbank fortlaufend anwachsen.
Da sie aber ja von Zeit zu Zeit mit Deiner
Entwicklungsversion übergemangelt wird,
ist das aber unerheblich.

Die Anwendungen, die ich an meine Kunden ausliefere, werden nicht übergemangelt. Durch das Umkopieren in die BackendDB haben die Kunden wieder das Wachstumsproblem. Sie müssen die FrontendDB komprimieren, womit wir wieder am Anfang meiner ursprünglichen Frage wären.

Ich glaube ich lasse meine aktuelle Anwendung wie sie ist, da ja das Kompriemieren der DB durch Applikationenwechsel funktioniert.

Ich gehe bei meinen Kunden so vor, daß ich
ein zentrales Netzwerkverzeichnis
einrichte, aus dem bei jedem Rechnerstart
eine frische (ggf. von mir aktualisierte)
Version der Frontend-DB geholt wird. Damit
ist die Frontent-DB immer wieder
kompiliert und komprimiert…

Werde ich in Zukunft machen.

Nochmal Danke für Deine Antworten.
Harald

#12

Dann dauert der Import bei großen Tabellen
leider unnötig lange, da ich die Tabelle
immer zweimal anfassen muß.

Na, so groß sind Excel-Tabellen doch meist nicht, das kann sich doch nur um Sekunden handeln. Wieso überhaupt Excel? Na egal…

Die Anwendungen, die ich an meine Kunden
ausliefere, werden nicht übergemangelt.

Wie das? Du mußt doch irgendwie eine neue Version ausliefern können - oder? Wo bleiben denn in Deiner derzeitigen Konstellation die Bewegungsdaten des Kunden?

Durch das Umkopieren in die BackendDB
haben die Kunden wieder das
Wachstumsproblem.

Ja, aber doch hauptsächlich in der Backend-DB - oder?

Sie müssen die
FrontendDB komprimieren, womit wir wieder
am Anfang meiner ursprünglichen Frage
wären.

Wenn man sie immer neu kopiert, dann nicht.

Ich glaube ich lasse meine aktuelle
Anwendung wie sie ist, da ja das
Komprimieren der DB durch
Applikationenwechsel funktioniert.

Ich kenne natürlich Deine Applikation zu wenig…

Reinhard

#13

Na, so groß sind Excel-Tabellen doch meist
nicht, das kann sich doch nur um Sekunden
handeln. Wieso überhaupt Excel? Na
egal…

Nun, meine Kunden verarbeiten Adreßdateien, die sie wiederum von Ihren Kunden bekommen. Das können Text-, Excel-, Access-, FocPro-, … -Dateien sein. Eben alles was vorstellbar ist. Leider wollen manche Kunden die Daten importieren und nicht nur verknüpfen. Das sind teilweise Dateien mit bis zu 1.000.000 Datensätzen (Excel natürlich nur bis 64.000). Da Kann das zweimalige Anfassen der Daten schon ein Zeitproblem werden.

Die Anwendungen, die ich an meine Kunden
ausliefere, werden nicht übergemangelt.

Wie das? Du mußt doch irgendwie eine neue
Version ausliefern können - oder? Wo
bleiben denn in Deiner derzeitigen
Konstellation die Bewegungsdaten des
Kunden?

Natürlich bekommen meine Kunden neue Versionen. Aber etwa nur im Abstand von mehreren Jahren. Bis dahin ist die Datenbank gewaltig angewachsen, wenn sie nicht ab und zu komprimiert wird.

Durch das Umkopieren in die BackendDB
haben die Kunden wieder das
Wachstumsproblem.

Ja, aber doch hauptsächlich in der
Backend-DB - oder?

Wieso, wenn ich die FrontendDB als Zwischenspeicher zum Umkopieren in die BackendDB verwende, wächst die doch genauso mit, da die gelöschten Datensätze nicht physisch entfernt werden, oder?

Harald

#14

Wieso, wenn ich die FrontendDB als
Zwischenspeicher zum Umkopieren in die
BackendDB verwende, wächst die doch
genauso mit, da die gelöschten Datensätze
nicht physisch entfernt werden, oder?

Daher mein Vorschlag, die Frontend-Datenbank nicht zu komprimieren, sondern beim Rechnerstart zu kopieren. (Hat sich übrigens auch bewährt, um korrupte Datenbanken zu vermeiden…)

Aber wie immer bei Access gibt es natürlich viele Wege zum Ziel. Wichtig ist m.E. nur, daß man sich nichts durch falsche Weichenstellung verbaut, was dann später nur mit großem Aufwand korrigierbar ist.

Reinhard