none
Sprung in der ID-Vergabe RRS feed

  • Frage

  • Hallo,
    ich habe das nun schon ein paar mal erlebt, dass der Index in einer Tabelle gleich mal einen Spring von 1000 macht, statt im 1-er-Schritt.

    Gibt es dafür eine Erklärung?

    Uwe


    Mittelung vom Forum

    Freitag, 22. September 2017 07:50

Antworten

  • Ja, die gibt es.

    Das liegt an dem internen identity-cache. Seit SQL Server 2012 beträgt dieser standardmäßig 1000.

    Vermutlich hattet ihr einen Shutdown von SQL Server zwischendurch.

    Mit dem Traceflag 272 kann man das auf das alte Verhalten zurücksetzen, aber das würde ich nicht empfehlen, außer es ist der Applikation wirklich wichtig (was wiederum auf unsauberes Design schließen ließe, denn der identity-Wert sollte wirklich "egal" sein)

    Eine andere Alternative wäre die Verwendung von SEQUENCEs, wo man den cache selbst definieren kann.

    In jedem Fall können natürlich immer noch Lücken auftreten. Das kann mit identity nicht komplett verhindert werden.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)


    Freitag, 22. September 2017 08:10

Alle Antworten

  • Ja, die gibt es.

    Das liegt an dem internen identity-cache. Seit SQL Server 2012 beträgt dieser standardmäßig 1000.

    Vermutlich hattet ihr einen Shutdown von SQL Server zwischendurch.

    Mit dem Traceflag 272 kann man das auf das alte Verhalten zurücksetzen, aber das würde ich nicht empfehlen, außer es ist der Applikation wirklich wichtig (was wiederum auf unsauberes Design schließen ließe, denn der identity-Wert sollte wirklich "egal" sein)

    Eine andere Alternative wäre die Verwendung von SEQUENCEs, wo man den cache selbst definieren kann.

    In jedem Fall können natürlich immer noch Lücken auftreten. Das kann mit identity nicht komplett verhindert werden.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)


    Freitag, 22. September 2017 08:10
  • Hallo Andreas,
    danke für die Erklärung. Wenn dem so ist, dann müssen wir unsere Programmierung ändern.

    Vielen Dank

    Uwe


    Mittelung vom Forum

    Freitag, 22. September 2017 08:30
  • ...
    Wenn dem so ist, dann müssen wir unsere Programmierung ändern.

    ...

    Dem ist in der Tat so ;-)

    Scherz beiseite: die großen 1000er-Sprünge kann man verhindern.

    Aber generell können eben jederzeit mal kleine Lücken z.B. durch Rollbacks entstehen. Wie "groß" "klein" ist, kommt auf die Transaktionen an. Bei Singleton-Inserts eben "1".

    Deswegen ist identity nur für interne Verwendung geeignet. Nicht für "Lückenlose" ID's. Siehe dazu auh diesen Thread: INSERT Statement - Erhöhung der ID je Datensatz

    Ich hoffe das hilft.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)



    Freitag, 22. September 2017 08:41
  • Hi Andreas,
    oft ist notwendig, bei der Datenerfassung Datensätze anzulegen, die jedoch z.B. beim Abbruch der Datenerfassung wieder gelöscht werden. Dadurch können auch Lücken in Autowert-Spalten entstehen. Das ist besonders ärgerlich, wenn z.B. fortlaufende Rechnungsnummern zu vergeben sind. Das kann man nur umgehen, indem man programmtechnisch eine Nummernspalte nutzt und rückgegebene Nummern in einer anderen Tabelle verwaltet und wieder bei der nächsten Neuanlage erneut vergibt.

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Freitag, 22. September 2017 10:03
  • Ja, das ist ein häufiger Grund. Der sich so oder anders lösen lässt.

    Zum Glück jedoch ist die Gesetzeslage gar nicht (mehr) so streng:

    "Die Oberfinanzdirektion (OFD) Koblenz hat klar gestellt, dass es bei der Vorschrift "fortlaufende Nummer" auf Rechnungen lediglich um die Einmaligkeit der erteilten Nummer geht (Verfügung vom 02. Juli 2008, Aktenzeichen: S 7280 A - St 44 5). Die Rechnungsnummern dürfen also je nach Kunden oder Produkten unterschiedlichen Text enthalten. Sie brauchen nicht lückenlos aufeinander zu folgen. "

    Daher brauch man sich für dieses Szenario die Mühe gar nicht machen, irgendeine Zahl rückwärts zu verwenden.

    Aber jetzt sind wir bei einem juristischen Thema.

    Ich habe zwar eine eigene Firma, aber bin kein Rechtsberater, insofern: Dieser Hinweis ist ohne jede Garantie. Bitte die jeweiligen Paragraphen selber nachrecherchieren.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Freitag, 22. September 2017 10:13
  • Hi Andreas,
    eine lückenlose fortlaufende Nummerierung innerhalb der Nummernkreise vereinfacht die Zusammenarbeit mit den Prüfern des Finanzamtes - jedenfalls meine Erfahrung.

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Freitag, 22. September 2017 10:40