none
identity_insert RRS feed

  • Frage

  • Hallo ich hätte da mal eine Verständnisfrage zu identity_insert.

    ich habe zu testzwecken mal eine Tabelle umbenannt und ein genaues Abbild unter dem ehemaligen Namen gespeichert. Nun wollte ich einfach Daten aus einen Skript in die Kopie speichern lassen und es klappt nicht mehr.

    Auf der Stundenlangen suche nach Skriptfehlern habe ich das gleiche dann im Management Studio versucht nachzuvollziehen und nun scheint es so das die Tabelle im Konflikt ist. Soll heißen in die Kopie kann ich nicht schreiben da identity_insert nicht auf On ist. Was ist der Hintergrund dafür?  

    Freitag, 15. Januar 2016 11:05

Antworten

  • IDENTITY hat direkt nichts mit einem PK Schlüssel zu tun, man verwendet es nur gerne dafür.

    Wenn Du eine 1:1 Kopie der ersten Tabelle erstellt hast, dann hat die auch die Identity Spalte.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 15. Januar 2016 15:20

Alle Antworten

  • Hallo Toot,

    wenn Du eine Tabelle umbenennst, so bleiben Einschränkungen Primärschlüssel- und Fremdschlüssel-Einschränkungen erhalten. IDENTITY_INSERT kann immer nur für eine Tabelle aktiv sein. Sind die Werte bereits vorhanden so gibt es bei vorhandenem eindeutigen Index (Primärschlüssel) einen Fehler. Gibt es Fremdschlüssel die auf andere Tabellen verweisen und deren Werte sind nicht vorhanden gibt es ebenfalls einen Fehler.

    Im Zweifelsfall poste bitte die genauen Fehlermeldungen, die Du im SSMS Meldungsfenster bekommst.

    Gruß Elmar
    • Bearbeitet Elmar Boye Freitag, 15. Januar 2016 11:14
    Freitag, 15. Januar 2016 11:13
  • Hallo,

    IDENTITY ist ja nun extra dafür vorgesehen, das der SQL Server selbst die Nummern automatisch fortlaufend für die Spalte vergibt. Wenn man hier eigene Werte einfügen will, muss man das dem SQL Server mit  identity_insert mitteilen, denn normalerweise "darf" man das nicht. Kleines Beispiel:

    CREATE TABLE [dbo].[IdentityTest](
    	[Id] [int] IDENTITY(1, 1) NOT NULL,
    	[Value] [varchar](50) NULL
    ) ON [PRIMARY]
    GO
    
    -- Einfügen eigener Werte in Spalte mit Identity
    SET IDENTITY_INSERT[dbo].[IdentityTest] ON;
    INSERT INTO [dbo].[IdentityTest]
       (Id, Value)
    VALUES
       (-100, 'Erster Wert');
    PRINT 'Hat geklappt';
    GO
    
    -- Gibt einen Fehler
    SET IDENTITY_INSERT[dbo].[IdentityTest] OFF;
    INSERT INTO [dbo].[IdentityTest]
       (Id, Value)
    VALUES
       (-111, 'Nächster Wert');
    GO
    
    DROP TABLE [dbo].[IdentityTest];

    Ergebnis:


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort vorgeschlagen Benjamin-UK Freitag, 15. Januar 2016 11:24
    Freitag, 15. Januar 2016 11:23
  • danke euch beiden! vor allem ein besonderes Danke an Olaf der sich so eine Mühe gegeben hat! Irgendwie bin ich aber im Wiederspruch mit beiden Aussagen. Olaf seine Aussage kann ich sofort nachvollziehen da tatsächlich ich ein autoinkrement sprich die in der ersten Spalte meiner Tabelle setzt sich eine ID automatisch als INT Wert und das stets um eins erhöht. Damit kann ich natürlich nicht einfach ein Insert machen und die ID selber hochzählen da ja insert identity aktiv ist.

    Soweit verstanden!

    Nun aber zu meiner Umbenennungsaktion ich habe ja nun folgendes getan "testtabelle" in "testtabelle_alt" umbenannt. Dann habe ich eine Tabelle angelegt die "testtabelle" heißt. alle Tabellen habe keine Schlüssel oder sonstiges. somit sollte es doch dem SQL Server egal sein oder? auch das zurück benennen von nun testtabelle_alt in wieder testtabelle sollte doch nicht zu Problemen führen?! also habe ich mir das Problem nur selber erstellt mit der Testerei?

    Freitag, 15. Januar 2016 15:10
  • IDENTITY hat direkt nichts mit einem PK Schlüssel zu tun, man verwendet es nur gerne dafür.

    Wenn Du eine 1:1 Kopie der ersten Tabelle erstellt hast, dann hat die auch die Identity Spalte.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 15. Januar 2016 15:20
  • nein ich habe keine 1:1 Kopie gemacht. Ich habe nur eben eine identische Tabelle erstellt und wollte dann mit einen insert into zu werke gehen aber da kam eben schon der insert into error. gibt es einen best practice für eine solche Kopie? insert into wäre mir am liebsten da ich ja noch eine where Klausel nutzen kann. also müsste ich beim nächsten mal nur auf insert identity on umstellen.
    Freitag, 15. Januar 2016 16:11
  • Ich habe nur eben eine identische Tabelle erstellt

    Auf die Gefahr pedantisch zu sein, aber eine identische Tabelle ist ein 1:1 Kopie mit den gleichen Eigenschaften, also auch mit Identity; hast Du die Tabelle mit dieser Eigenschaft erstellt?

    Die einfachste Art eine flache Kopie einer Tabelle inkl. (gefilterten daten) ohne sonstige Eigenschaften wie eben Identity zu erstellen, ist eine SELECT .. INTO Anweisung zu verwenden, also

    SELECT *
    INTO neueTabelle
    FROM alteTabelle
    WHERE ...
    "neueTabelle" wird dann mit den gleichen Spalten & Datentypen angelegt, wie "alteTabelle", nur ohne PK, Indizes, etc.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 15. Januar 2016 19:27
  • natürlich - wenn ich schon Fehler mache dann aber richtig! ok das habe ich jetzt gerafft, die Probleme habe ich mir selber erstellt und dann auch noch weiter gepflegt. Danke für deine Hilfe und deine Geduld.  
    Samstag, 16. Januar 2016 12:02