IDENTITY Felder wieder auf 0 setzen?

[Peter A. Smolik]

Hab hier zwar eine Menge Beispiele gefunden wie man die Identity Felder quasi abschalten kann wenn man einen Import macht, aber leider nicht wie man diese Felder auf 0 bzw. 1 setzen kann.

Womit sich natürlich die Frage aufwirft wie setze ich dann das Feld so das der nächste autinc-Wert ein gültiger Wert ist.

Aber mein Problem ist definitv das ich alle Datensätze löschen möchte und von vorne zu zählen beginnen möchte.

Gibts da eine andere Möglichkeit als Drop Table und Re-Create?

LG
Peter

[Andreas Kosch]

Hallo,

die Frage ist, wozu das Zurücksetzen auf 0 gut ist? Nach der Datenbank-Theorie hat der Primärschlüssel nur die Aufgabe, einen Datensatz logisch eindeutig in der Menge zu kennzeichnen. Und für diese Aufgabe spielt der tatsächliche Wert überhaupt keine Rolle. Ein Primärschlüssel sollte nicht für das Kodieren einer fachlichen Information "missbraucht" werden (denn damit würde man Ärger provozieren, wenn sich später die fachlichen Bedingungen ändern)

[Andreas Wohlmuth]

Hallo,

das mit dem Zurücksetzen habe ich mir auch schon überlegt. Grund war eine Tabelle die nur zum Import verwendent wird, aber da braucht man dann eigentlich keine ID.

Gibts in SQL-Server eine Art Generator wie bei Interbase,Oracle

[Dietmar Wintzheimer]

Hallo, <br>
mit dem zuruecksetzen bin ich einer Meinung wie Andreas Kosch. <br>
a) es macht wirklich keinen Sinn den Wert zu ändern<br>
b) das Datenbankdesign und die Programmierung darf auf eine solche Änderung nicht ausgelegt sein.<br>
c) Gefahr, keine Eindeutige Key's <br>
Jedoch zeigt die Praxis, dass ein "zurücksetzen" (zwar in seltensten Fällen -
aber mit Hintertürchen) für gewisse Unannehmlichkeiten gar nicht so schlecht ist. <br>
Man hat nicht immer auf Anhieb das perfekte Design und die Kundenprozesse und Anforderungen ändern sich im Laufe ...<br>
vor allem während der Entwicklung
<p>
Zur anderen Fragen mit dem Generator und dem Zurücksetzen :<br>
Vorraussetzung ist, dass ein ID-Feld mit dem Datentyp Integer vorhanden ist <br>
1) Tabelle bearbeiten<br>
2) Primary Key vom ID-Feld entfernen<br>
3) beim ID-Feld , unten IDENTITY auf NEIN, MUSS-Feld zum Kann-Feld<br>
4) speichern und verlassen<br>
5) Tabelle bearbeiten<br>
6) ID-Feld löschen<br>
(macht eigentlich nur dann Sinn wenn auch keine Daten mehr in Tablle sind, geht aber auch so)<br>
7) speichern<br>
8) ID-Feld als Integer Feld anlegen<br>
(beachte kein MUSS-Feld)<br>
9) speichern und verlassen<br>
10) neuen Datensatz anlegen, bzw. ID-Felder neu vergeben (1, 2, 3, ...)<br>
11) Tabelle bearbeiten<br>
12) ID-Feld mit Primary-Key versehen, MUSS-Feld und unten IDENTITY auf JA setzten<br>

Gruesse
Dietma

[Peter A. Smolik]

Danke Dietmar,

Ich wollte hier keine Grundsatzdiskusion beginnen, sondern wie ich eindeutig erklärt habe in einer !!!! LEEREN !!! Tabelle die AutoInc Felder zurücksetzen.

Ich kann mich der Ansicht des Herrn Kosch nicht anschließen. Ein Primary-Key Feld ist keine mißbrauchte fachliche Information sondern einfach die schnellste Variante um einen und nur einen spezifischen Datensatz zu finden.

Wenn man nun wie in meinem Falle eine Planungstafel aufbaut deren Lebensdauer begrenzt ist auf den sogenannten Tagbetrieb (in der Nacht läuft ein neuer Planungslauf) dann können das unter Umständen ein paar hunderttausend Datensätze sein. (im konkreten Fall 496.878) Um in dieser Datenmenge etwas schnell und zuverlässig zu finden bietet sich der AutoInc-Primary Key einfach super an.

Wenn dann die User den Wunsch haben das diese Zahl nicht immer länger und länger und länger wird dann ist das meiner Meinung nach auch gerechtfertigt. Schließlich muß der Plannungsdisponent 8-12 Stunden täglich diese Zahlen in sein Modell eintippen. Oder der Programmierer erzeugt einen zweiten Index mit einer Pseudozahl die jede Nacht zurückgesetzt wird bzw. anstatt eines AutoInc-Feldes.

Da dieser Nachtjob aber auf mehreren Servern zur gleichen Zeit läuft um alle Daten in der vorhandenen Zeit abzuarbeiten müßte man wiederum sowas wie einen Generator programmieren um nicht doppelte Zählerwerte zu bekommen. Ein ungleich hörer Aufwand mit sicher deutlich schlechterer Performance als das AutoInc Feld.

Daher hab ich nach einer Methode gesucht um das Zurücksetzen der Tabelle zur Laufzeit des Nachtjobs zu machen.

LG
Pete

[Olaf Steffan]

Hallo zusammen,<BR><BR>ich habe gerade jetzt nach meinem Urlaub diese Diskussion gelesen und kann es mir doch nicht verkneifen auch meinen Senf dazuzugeben ;-)!<BR>Auch ich vertrete eigentlich den Grundsatz, dass eine IDENTITY keinen "inhaltlichen Wert" haben sollte. Man kann das Problem von Peter natürlich dann nachvollziehen, wenn die Zahlen immer größer werden und die Mitarbeiter dann irgendwann riesige Zahlen eingeben müssen. So wie ich es verstehe dient die Zahl ja auch nur dazu einen selektierten Datensatz später (innerhalb von 24-h) wiederzufinden, wobei mir allerdings nicht klar ist, wie dieser Datensatz erst einmal gefunden wurde. Das läuft doch sicherlich über andere Felder...?!<BR>Wie dem auch sei, es gibt eine ganz einfache Lösung - TRUNCATE TABLE .... setzt die Autoincrement IDENTITY wieder zurück.<PRE>create table aaa(ID int identity(1,1), a int)
insert into aaa values(1111)
insert into aaa values(2222)
select * from aaa --(1, 1111 ; 2, 2222)
truncate table aaa
insert into aaa values(2222)
insert into aaa values(1111)
select * from aaa --(1, 2222 ; 2, 1111)
drop table aaa
</PRE>Das löst auch das Import-Problem von Andreas.<BR><BR>Viele Grüße Ola