Hallo,
eine Frage, deren Netz-Anworten mich irritieren.
Zur Lage: Das BE liegt auf einem Terminal-Server, die FE der 5 User auf ihren APC.
Wenn ich das FE zum Beispiel 1x in der Woche komprimiere/repariere wird dann dass BE mit erfasst, wenn der letze User die Anwendung beendet?
Oder muss ich das BE gesondert komprimieren/reparien?
ZitatOder muss ich das BE gesondert komprimieren/reparien?
Was gäbe es zu reparieren?
Und ja, das Backend ist gesondert zu komprimieren, und zwar dann, wenn keine sonstigen Zugriffe darauf erfolgen.
Hallo hawebe,
bei einer "normalen" Nutzung des Backends, also ohne exzessiven Einsatz von Insert- und Löschabfragen, sollte die (regelmäßige) Komprimierung eigentlich kein Thema sein.
Hallo,
danke für Euere Antworten.
Das BE wird intensiv genutzt, weil die Anwendung das komplette Fakturierungsprogramm einer Etikettendruckerei ist. Es gibt also arbeitstäglich eine Menge an Löschungen in Tabellen.
Das FE ist eine .accdb und müsste somit nicht komprimiert werden.
Habe ich Euch richtig verstanden, dass unter diesen Voraussetzungen nur das BE komprimiert werden muss?
Hallo,
ZitatEs gibt also arbeitstäglich eine Menge an Löschungen in Tabellen.
reglelmäßig notwendige Löschungen sollte es in einer fertigen DB nicht geben.
Außer bei falschen Eingaben, aber dann sind nur Daten zu löschen.
Was sit denn der Grund für die Löschungen ?
Hallo MzKIMu,
alle Bewegungen in der db sind saisonal unterschiedlich. Bei durchschnittlicher Nutzung kann das BE in einer Woche von 36 MB auf 40 MB zunehmen. In der Vorweihnachtszeit können es auch 42 MB werden.
Über einen längeren Zeitraum habe ich die Entwicklung noch nicht beobachtet, weil ich dann manuell komprimiere.
Ich brauche also eine Strategie, weil mein Leben (Jahrgang 1945) endlich ist.
Hallo,
ZitatBei durchschnittlicher Nutzung kann das BE in einer Woche von 36 MB auf 40 MB zunehmen. In der Vorweihnachtszeit können es auch 42 MB werden.
Wenn die Zunahme durch mehr Daten erfolgt, ändert auch eine Komprimierung nichts.
Zu den Löschungen hast Du jetzt kein Wort verloren, warum müssen regelmäßig Daten gelöscht werden ?
Na ja,
hat eigentlich mit den Fakten nichts zu tun. Aber wenn es hilft:
Es gibt täglich Löschungen,
- wenn auf Angebote keine Bestellungen erfolgen,
- wenn sich Lieferanten für Papiere/Folien ändern, Stanzen nicht mehr funktionsfähig sind.
- Kunden versterben, Insolvent werden, Geschäft aufgeben (30.000 Ds)
Es gibt insgesamt 9 Tabellen, in denen Löschungen erfolgen können.
Also glaub mir, ich brauche eine Strategie. Darauf zielte auch meine Eingangsfrage.
Hallo,
was für eine Strategie ?
Komprimiere doch einfach. Die DB muss allerdings exclusiv geöffnet sein.
Du kannst auch einstellen, dass das BE bei jedem Beenden automatisch komprimiert wird.
In allen von Dir geschilderten Fällen halte ich das Löschen von Daten für den falschen Weg.
Man löscht in einer DB keine Daten die mal gültig waren.
ZitatKunden versterben, Insolvent werden, Geschäft aufgeben (30.000 Ds)
30.000 solcher Kunden, wirklich ?
Nicht mehr benötigte Daten werden durch ein Kennzeichen ausgefiltert, bleiben aber in der DB.
Hallo Ha-Wo,
schau Dir dieses an:
http://www.donkarl.com/?FAQ6.7
https://msdn.microsoft.com/de-de/library/bb978984.aspx
wobei ebs17 schon darauf hingewiesen hat, dass kein anderer User die Db im Zugriff haben darf
http://dbwiki.net/wiki/VBA_Tipp:_Aktuelle_Benutzer_ermitteln
Hallo Franz,
ich habe Deine Links geöffnet und bin der Meinung, dass ich eine Benutzerfeststellung nicht benötige. Einer der Nutzer ist immer der Letzte, so dass die Komprimierung durchgeführt werden sollte. Ich denke, dass 1x wöchentlich für die Komprimierung ausreicht. Dazu habe ich vor, Auto Compact von Th. Möller beim Beenden des FE zu verwenden (für meine Fähigkeiten die überschaubarste Lösung).
If Weekday(Date, vbMonday) = vbFriday Then
SetOption "Auto Compact", True
Else
SetOption "AutoCompact", False
End If
Was meinst Du zu meiner Absicht und kann ich davon ausgehen, dass das BE auf demTerminalserver dann auch komprimiert wird?
Hallo MzKIMu,
Du hast Recht, die Zahl stammte noch aus der Datenübernahme von Access 2.0.
Derzeit sind es:
2649 Kunden
16.246 Rechnungsdaten
14.287 Stammdaten (Lieferhistorie)
Hallo,
Zitat2649 Kunden
16.246 Rechnungsdaten
14.287 Stammdaten (Lieferhistorie)
Das ist eher noch eine Kleinigkeit für Access. Um so mehr bin ich der Auffassung, dass das Löschen von Daten mit obiger Begründung der falsche Weg ist. Und wenn Du nichts löschst, brauchst Du auch nicht komprimieren. Das wäre meine Strategie.
Das Freigeben von nicht mehr benötigten Speicher ist nur eine Seite des Komprimierens.
Beim Komprimieren werden auch Indizes neu geordnet und Tabellenstatistiken (die dem Abfrageoptimierer als Basis dienen) aktualisiert.
Hallo,
@Ebs
aber wenn keine Daten gelöscht werden, müssen doch auch keine Indizes neu geordnet werden. Und neu hinzukommende Daten führen die Indizetabellen doch einfach fort.
Und wenn ich mich nicht irre, bist Du auch gegen das regelmäßige Komprimieren wenn es keinen Grund gibt.
Nun, ob Löschen Sinn macht, ergibt sich auch aus der Anwendung selber. Verarbeiten von nur tagesaktuellen Daten ist etwas anderes als historisch nachvollziehbares Sammeln von Daten.
Ich bin vor allem gegen das Erzeugen und Verwerfen von Temp-Müll in einem Backend mit Stammdaten wie auch in einem Frontend, also
- gegen Standardimporte von Dateien, mit denen man so nichts anfangen kann,
- gegen das Ablegen von Zwischenergebnissen.
Solches Auf und Ab zumindest in größeren und öfteren Umfängen gehört in ein zusätzliches lokales temporäres Backend, da so die eigentlichen Arbeits-DBs nicht belastet werden.
Man darf sich dabei auch die Situation vorstellen, dass man sich durch extensives Erzeugen von Temp-Müll in die Lage bringen kann, sofort zur Laufzeit komprimieren zu müssen, was dann in einem intensiveren Mehrnutzerbetrieb problematisch ist.
Ein eigenes Temp-BE kann man immer wegwerfen, ohne Auswirkungen auf Dritte.
Hallo,
nachdem ich die DB von hawebe etwas detaillierter kenne, als es hier aus dem Thread hervorgeht, ist die an sich richtig dargestellte Umstellung der Tabellen- und Formular-Struktur hier keine Option. Der Aufwand stünde in keinem Verhältnis zu einer völligen Neuentwicklung, die die dargestellten Alternativen zur Komprimierung und viele andere Themen (Beziehungen, Normalisierung, Code, Installation, etc.) berücksichtigt.
Es müsste ein neues Grundkonzept projektiert werden, was aber aus bekannten Gründen nicht realistisch ist.
m. E. steht in diesem Fall tatsächlich nur die zeitweise manuelle Komprimierung des BE (was auch auf einem TS funktioniert) zur Verfügung.
PS: mit "manuell" meine ich das manuelle Anstoßen der VBA-Prozedur (z. B. mit einem Klick auf einen Button) zur Komprimierung des BE in einem Verzeichnis auf dem TS
Hi,
Eure Diskussion zeigt mir, dass meine Irritation aus Netz-Informationen nicht unbegründet waren wenn Ihr Euch selbst nicht einig seid.
Meine Anwendung muss auch noch nach meinem Ableben laufen. Und ich brauche eine Komprimierung, weil
Daten gelöscht werden müssen. Erstens macht der Bearbeiter Fehler bei Erstellung von Angebote/Aufträgen und zweitens
müssen Angebote nach 30 (Frist) gelöscht werden. Eine Umbuchung ergäbe nun gar keinen Sinn. Und nach allem was ich bisher gelesen habe, beschleunigen kleinere Tabellen die Suche.
Ich bitte Euch daher nur um Antwort auf die Frage, ob eine im FE verankerte Komprimierung auch das BE (auf dem Terminalserver) mit erfasst.
Hi,
wie wär's mit einfach mal Ausprobieren?! ;-)
Hi,
Eure Diskussion zeigt mir, das meine Irritation aus den Netz-Informationen nicht unbegründet waren wenn Ihr Euch selbst nicht einig seid.
In meiner db müssen Daten gelöscht werden. Das Warum entscheide ich. Und da die Anwendung auch nach meinem Ableben noch laufen muss, wird sie auch komprimiert.
Meine Frage dazu war, ob bei einem im FE verankerten Komprimierung auch das BE (Terminalserver) mit einbezogen wird.
Wenn Ihr mir dazu bitte mit Ja oder Nein antworten könntet?
Hallo,
hatte das vorher erwähnt.. Es ist egal, wo das BE liegt. Solange es über opendatabase erreichbar ist, kann es auch komprimiert werden. Eine größere Problematik sehe ich darin, dass alle User ihre Access-Session beendet haben, bevor komprimiert wird.
Hallo,
Zitatmüssen Angebote nach 30 (Frist) gelöscht werden. Eine Umbuchung ergäbe nun gar keinen Sinn.
von Umbuch war auch keine Rede, sondern von Kennzeichnung, was aber hier auch überflüssig ist, denn es gibt ja ein Kriterium (30 Tage) zum Ausfiltern alter Angebote.
Zitatbeschleunigen kleinere Tabellen die Suche.
aber nicht bei diesen kleinen Datenmengen. Und auch bei großen Datenmengen spielt eine Indizierung die weitaus größere Rolle.
ZitatWenn Ihr mir dazu bitte mit Ja oder Nein antworten könntet?
Die Antwort dazu steht bereit in der 1. Antwort von Ebs17.
Zitat von: Ebs17 aus #1Und ja, das Backend ist gesondert zu komprimieren, und zwar dann, wenn keine sonstigen Zugriffe darauf erfolgen.
Hallo Franz und sorry,
ich hatte übersehen dass es mittlerweile eine Seite 2 zu den Diskussionsbeiträgen gibt und daher eine Antwort 2x versandt.
Hinsichtlich Deiner Bedenken zum Ende der Session: Der User, der die Anwendung beendet ist immer der, der die Firma als Letzter verläßt. Access wird sonst nicht weiter genutzt.
So müsste es doch funktionieren?
Hallo,
ja.... :)
ZitatSo müsste es doch funktionieren?
Sauber wäre es etwa so:
- Beim Schließen des Frontends in ein ungebundenes Formular übergehen, damit eigene Zugriffe (gebundene Formulare, Recordsets usw.) abgeschlossen sind.
- Dateigröße des Backends ermitteln (VBA.FileLen), bei Überschreiten einer festgesetzten Grenze weiter in den Prüfungen
- Backend auf Zugriffsfreiheit testen siehe sinngemäß Datenbank-Backup aus VBA (http://www.ms-office-forum.net/forum/showpost.php?p=680108&postcount=5)
- bei erfüllter Prüfung Backend komprimieren (CompactDatabase), siehe z.B. Backend komprimieren? (http://www.ms-office-forum.net/forum/showthread.php?t=273281)
hawebe, korrigiere bitte deine Email-Adresse, bekomme bei jeder Antwort auf den Thread eine Fehlermeldung per Email!
Andreas