Komprimieren von FE und BE

[hawebe]

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?

[ebs17]

Oder 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.

[MaggieMay]

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.

[hawebe]

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?

[MzKlMu]

Hallo,

Es 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 ?

[hawebe]

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.

[MzKlMu]

Hallo,

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.

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 ?

[hawebe]

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.

[MzKlMu]

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.

Kunden 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.

[DF6GL]

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

[hawebe]

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?

[hawebe]

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)

[MzKlMu]

Hallo,

2649 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.

[ebs17]

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.

[MzKlMu]

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.