Office: (Office 2007) Autowert auf 0 setzen

Hallo zusammen,

Ich hab ne Tabelle, in welcher jeder neue DS einen Index verpasst bekommt. Diese spielt lediglich innerhalb dieser Tabelle eine Rolle, in Punkto Dublettenidentifikation. In der weiteren Verwendung der Datensätze spielt der Index keine Rolle.

Wöchentlich wird diese Tabelle geleert. Wie kann ich den Autowert nach der Leerung der Tabelle wieder auf 0 setzen?

Besten Dank!

:)

 

Hallo,
komprimieren/reparieren aus den Datenbanktools sollte das erledigen.

 

Hallo Klaus,

danke für die schnelle Antwort. Komprimieren erfolgt beim Schließen - der Autowert klettert aber immer höher und höher! Er setzt quasi immerwieder an dem Punkt an, an welchem er vor der Löschung aufhörte!

 

Hallo,
kann ich nicht nachvollziehen, ist die Tabelle vollständig leer?

 

Hallo!

Grundsätzlich lässt sich der Autowert per DDL-Anweisung auf den gewünschten Wert setzen. Ich frage mich nur, warum du den Wert zurücksetzen willst, wenn er sowieso keine Rolle spielt. Für die Dublettenidentifikation ist doch die Zahl egal, oder?

DDL-Anweisung:
Code:

.. z. B. mit Currentdb.execute ausführen ... dann beginnt der erste Autowert mit 0.

mfg
Josef

 

\@gpswanderer: Ja, die tabelle wird wöchentlich vollständig ins Archiv verschoben ... besser gesagt wird der gesamte Tabelleninhalt verschoben.

hallo Josef,

Prinzipiell ist das alles richtig - explizit für die Dublettensuche sowie auch ganz allgemein für die Vorgänge in meiner DB stellt mich das vor keine Probleme.

Es sieht halt lediglich unschön aus, wenn ich die werte importiere und die ID startet bei 1.005.452 ... dem schließt sich folgende Frage an: zwar ist es unwahrscheinlich an die Grenzen des Long Integer Wertes zu gelangen - aber rein hypothetisch könnte dies passieren. haben hohe Werte auswirkungen auf die Performanz? Würdest du mir davon abraten?

Also mein Wunsch hat vordergründig stilistische Gründe, keine technischen!

Danke für eure Hilfe

 

Aus der Hilfe: Variablen vom Datentyp Long (lange Ganzzahl) werden als 32-Bit-Zahlen (4 Bytes) mit Vorzeichen im Bereich von -2.147.483.648 bis 2.147.483.647 gespeichert.
Wie die 32 Bits gefüllt werden (1 oder 0), dürfte sehr egal sein, die Größe von 32 Bit ändert sich nicht.

Man könnte temporäre Daten auch in einem Extra-Backend führen. Nach Abschluss der Verwendung löscht man dieses ganze Backend und erzeugt es bei erneutem Bedarf per Code neu inklusiv der Tabelle und der nötigen Verknüpfung ins Frontend.
So hätte man zum einen immer einen sauberen Counter, der bei 1 anfängt, und zum anderen erzeugt man im Backend für die Stammdaten keinen Druck auf Notwendigkeit des Komprimierens.

 

Hallo

Ist die Datenbank vielleicht in Frontend und Backend aufgeteilt? Wann ja, musst Du das Backend komprimieren und reparieren.

 

Es gibt verschiedene Backends - das betroffene ist für die aktuelle zu bearbeitenden DS vorgesehen - allerdings enthält dieses auch Tabellen welche dauerhaft im Backend verbleiben - von daher preferiere ich derzeit die lösung den Autowert mittels Code wieder zurückzusetzen.

@ebs Ne sehr schöne Idee, doch rennt bei mir die Zeit etwas weg - aber ich werd`s mal ausprobieren!

Noch ma blöd gefragt: wo stell cih das mit dem reparieren ein - habs irgendwie nicht finden können - oder setzt man dies via VBA um?

 

Hast du so wenig Zeit, dass du die Vorschläge in den Beiträgen nicht einmal ausprobieren kannst? Mit der DDL-Anweisung kannst du nämlich auch ohne Komprimieren den Autowert einstellen. ;-)

Bezüglich Speicherplatzbedarf ist es egal ob eine 1 oder die Zahl 1.234.567.890 gespeichert ist. Für die Indexsuche ist die Größe auch egal - außer die Größe der Zahl ergibt sich aus der Anzahl der Datensätze. ;-)
BTW: falls du beim Autowert an die Long-Grenze kommst, beginnt der Autowert mit dem negativen Zahlenbereich und arbeitet sich dann auf 0 vor, um dann wieder bei 1 zu beginnen.

mfg
Josef

 

Hallo

Ich will keineswegs die Vorschläge der Gurus hier in Frage stellen.

Ich frage mich, weshalb es nicht reicht, das betreffende Backend zu komprimieren und reparieren. Die anderen Tabellen werden doch davon nicht betroffen. Beim Komprimieren werden lediglich die Autowerte der leeren Tabellen auf 0 zurückgesetzt. Bei anderen Tabellen mit Inhalt wird der Autowert auf den letztmöglichen Wert zurückgesetzt. Bestehende Autowerte werden nicht geändert.

 

Das Komprimieren kann auch problembehaftet sein. Besonders das automatische Komprimieren bei Schließen der DB ist leicht buggy. Daher sollte man nicht gar so leichtfertig damit sein.
Besonders aber wird das Komprimieren gerne benutzt, um Temp-Müll (aufgeblasene und danach geleerte Tabellen => aufgeblähte DB) zu beseitigen. Da Forza SGD schon von Stil sprach: Müllvermeidung ist stilvoller als Müllbeseitigung, und das hieße dann z.B., tempörare Daten von den Stammdaten und deren Backend fernzuhalten.

Auch: Sehr wahrscheinlich ist die Anlage des Counters zur Duplettenidentifikation ein Workaround, geschuldet der knappen Zeit. Mit entsprechenden Methoden kann man auch Duplikate in Stammdaten von Haus aus vermeiden statt diese zur Beseitigung identifizieren zu müssen. Sprich: Bei manchen geplanten Abläufen entstehen gewisse Probleme gar nicht erst.

 

\@Eberhard

Ich bin auch davon ausgegangen, dass explicit das Backend komprimiert und repariert wird. Das automatische Komprimieren bei Schliesen einer DB ist tatsächlich weder Fisch noch Vogel.

Doch sonst. Was spricht dagegen, das Backend zu komprimieren und genau den Zustand zu erreichen, den der Threadstarter erreichen will?

 

Ein rund um die Uhr genutztes Backend im Mehrnutzerbetrieb? Aktionen an einem File-Backend im Zugriff sollte man tunlichst unterlassen.

Ich beherzige einen Hinweis von Josef Pötzl: Auch wenn ich an einer kleinen DB bastele, tue ich so, als wäre es eine richtige Datenbank mit wirklich vielen Datensätzen in der intensiven Nutzung (Ausfall = Problem!) - schon wegen der Gewohnheitsbildung. Da braucht man dann später nicht umlernen und umbauen. Erfolg der eigenen Anwendung sollte man nicht ausschließen ...

Und noch einmal: Die Rückstellung eines Autowertes auf 0 in einer durchgeplanten DB ist unnötig und überflüssig, damit verbundene Maßnahmen dann ebenso.

 

\@Eberhard

Was soll jetzt das heissen

Davon war ja nie die Rede.

Und was soll diese Bemerkung im Klartext heissen?

Du redest unverständlich.