Komprimieren von FE und BE

[ebs17]

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.

[DF6GL]

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

[hawebe]

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.

[MaggieMay]

Hi,

wie wär's mit einfach mal Ausprobieren?! ;-)

[hawebe]

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?

[DF6GL]

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.

[MzKlMu]

Hallo,

mü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.

beschleunigen kleinere Tabellen die Suche.

aber nicht bei diesen kleinen Datenmengen. Und auch bei großen Datenmengen spielt eine Indizierung die weitaus größere Rolle.

Wenn Ihr mir dazu bitte mit Ja oder Nein antworten könntet?

Die Antwort dazu steht bereit in der 1. Antwort von Ebs17.

Und ja, das Backend ist gesondert zu komprimieren, und zwar dann, wenn keine sonstigen Zugriffe darauf erfolgen.

[hawebe]

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?

[DF6GL]

Hallo,

ja....   

[ebs17]

So 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
- bei erfüllter Prüfung Backend komprimieren (CompactDatabase), siehe z.B.  Backend komprimieren?

[Hondo]

hawebe, korrigiere bitte deine Email-Adresse, bekomme bei jeder Antwort auf den Thread eine Fehlermeldung per Email!

Andreas