Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Identity Felder nach Umstellung auf SQL SERver von MySQL

Begonnen von trekking, Oktober 27, 2024, 21:10:42

⏪ vorheriges - nächstes ⏩

trekking

Hallo Miteinander,
mit dem MS Migrationstool migriere ich von MYSQL 5.0 auf SQL Server 2019.
Das klappt besser als erwartet, hat aber ein paar Probleme. Eines davon ist dass normale Spalten, die integer sind aber kein autoincrement in Identity Felder umgewandelt werden.
An der Stelle ist das allerdings nciht gewollt, da die Schlüssel selbst verwaltet werden.
Nun scheint es nicht möglich zu sein, diese Felder einfach auf IsIdenty = no zu stellen. Es geht zwar im Managementstudio optisch, dies scheint aber keine Auswirkung zu haben.
Gibt es eine einfache Möglichkeit das zu ändern oder muss ich tatsäclich die Idetnity Felder löschen. (Mit vorher kopieren etc)
Hauptsächlich geht es mir darum, dass ich dann alle Verknüpfungen wieder neu machen muss.

Hoffe ich habe mich verständlich ausgedrückt.
Danke für Eure Unterstützung.

Viele Grüße
trekking

Bitsqueezer

Hallo,

in SSMS kannst Du in den Optionen einstellen, ob Änderungen an Tabellen erlaubt sein sollen.
"Prevent saving changes that require table re-creation" heißt die Option.

Wenn Du das abschaltest, erstellt SSMS im Hintergrund ein Skript, das bei Speicherung von Designänderungen automatisch eine neue Tabelle erstellt, alle Änderungen dort speichert, Deine Daten hineinschiebt, die Beziehungen darauf wieder korrekt herstellt und führt es aus.

Du kannst dabei (wie bei allen Operationen in SSMS) oben mit dem Script-Icon das, was Du mit der GUI machst, auch als Script ausgeben lassen, wenn Du dem Vorgang nicht traust.

Ich nutze das aber mit auch sehr komplexen Datenbanken schon seit zig Jahren und hatte noch nie ein Problem.
Als SSMS-User sieht es einfach so aus, als würdest Du halt eine Änderung am Design speichern.

Identity läßt sich auf diese Weise problemlos abschalten.

Gruß

Christian

trekking

Danke Chrsitian,

vor allem für die Erklärung mit den Scripten.
Die Einstellung
"Prevent saving changes that require table re-creation"
habe ich eingestellt.
Das Identity= no lies sich auch einstellen.
Nur die Fehlermeldung, dass ich in ein Identity Feld schreiben will, habe ich immer noch erhalten.
Das habe ich nicht so richtig verstanden.
Hatte allerdings bei meinen weiteren Migra - experimenten in der MySQL DB den Autowert herausgenommen. dann war das Problem erstmal weg.

Gibt es irgendwas, das verhindert, dass das "wirkt"?


Ist schon strange.

Viele Grüße
trekking

Bitsqueezer

Hallo,

wenn Du die Tabelle richtig geändert und das Design gespeichert hast, ist das ID-Feld, das vorher Identity war, ein normales int-Feld, das Du beschreiben kannst.

Kannst Du daran erkennen, wenn Du die Tabelle im Edit-Modus (rechte Maustaste auf der Tabelle) öffnest: Ein Identity-Feld ist immer ausgegraut, wenn Identity entfernt wurde, kannst Du es editieren.

Nebenbei kannst Du auch ein Identity-Feld beschreiben, wenn Du "SET IDENTITY" verwendest, Syntax mußt Du nachlesen. Geht immer nur mit einer Tabelle gleichzeitig und dient dazu, Daten in Tabellen mit Identity-Spalte zu schreiben, ohne Identity entfernen zu müssen. Nicht vergessen, daß die IDs natürlich zu den Foreign Keys passen müssen.

Gruß

Christian

trekking

Hallo Chrsitian,

auf das ausgegraut muss ich nochmal achten.
Das mit dem
"SET IDENTITY_INSERT dbo.MeineTabelle ON"
habe ich getestet und benutze es wenn ich Werte in eine leere Tabelle eintrage.
Wenn ich aus Access eine Tabelle übertrage per ODBC Verknüpfung benutze ich den Befehl im SSMS zuvor. Allerdings ist mir da aufgefallen, dass ich etwas geduldig sein muss und nicht gleich den Insert machen kann. Habe ich nicht verstanden warum.

Werde es nochmal beobachten und berichten.

Viele Grüße
trekking

Bitsqueezer

Hallo,

das ist nur für den Zweck gedacht, wenn man mal Werte in eine Lookup-Tabelle übertragen will, ohne gleich das Design der Tabelle anpassen zu müssen. Das ist nicht für den "täglichen Betrieb" im Rahmen einer Anwendung, weil das auch nur für eine Tabelle in einer Session gleichzeitig gemacht werden darf.

Gruß

Christian

trekking

Hallo Christian,

das war auch so gemeint mit "Werte in eine leere Tabelle eintrage".
Hatte ja geschrieben, dass ich  gerade von MySQL auf SQL SERver migriere. Da das leider nicht in einem Schritt mit dem MigraTool geht poppen diese Probleme auf.
Würde man den Befehl dauerhaft brauchen, stimmt sicher was mit dem Datenmodell nicht :)

Viele Grüße
trekking