Migration von LocalDB nach SQL Express Edition

  • VB.NET

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von Nofear23m.

    Migration von LocalDB nach SQL Express Edition

    Hallo Leute,
    Bräuchte ein paar Tips um die Weiterentwicklung meines Visual Studio Projektes in die richtige Richtung zu lenken.
    (anders ausgedrückt hab keine Ahnung wie es weiter gehen soll.... ;) )

    Hier mal die Laage...
    Ich habe mir ein kleines VS 2015 Projekt zusammen programmiert welches Daten in eine .MDF Datenbank speichert. Die .MDF-Datenbank hat mir VS dank Code-First technologie automatisch erstell. Den zugriff auf die DB erledigt LocalDB, hab gar kein SQL auf meinem Rechner installiert. (außer vielleicht von VS, bin mir aber nicht sicher wie das geregelt wird..)
    Das funktioniert hier bei mir zuhause auf meinem Rechner ganz gut.
    Seit beginn war mir aber klar, dass die Anwendung später mal auf einem Rechner auf meiner Arbeit laufen sollte. Was in unserer Firma nicht so einfach ist....
    Es sollte gar keine so grosse Sache werden. Ziel war es bloß Arbeitsdaten auf eine praktischen Weise speichern zu können. Excel ist mir bei großen Tabellen einfach zu unübersichtlich.

    Um das ganze so einfach wie nur möglich zu halten, habe ich sogar vor das Programm gar nicht mal auf dem Firmenrechner zu installieren , sondern bloß die Bin/debug Projektdateien drauf zu kopieren. Und von da aus die Projekt.exe-Datei zu starten.

    Soweit so gut, wäre da nicht das Problem der Datenbank... Und was die anbelangt hatte ich mir vorgestellt, unser IT-Service würde mir "erlauben" LocalDB auf meinen Firmenrechner zu installieren. Und so wäre meine Anwendung dann in der Laage auf die .MDF-Datenbank zuzugreifen welche ich auf unseren Firmenserver ablegen würde.
    Aber damit waren die IT-Kollegen unerwarteter Weise nicht einverstanden. Sie haben mir angeboten meine .MDF-Datei auf einen Firmenserver abzulegen auf dem eine SQL Express Edition drauf installiert ist. Die waren "gütiger" als ich bei Beginn meines Projektes zu träumen wagte.
    Also so viel mal zum aktuellen Stand der Dinge.
    Aber ab hier weiß ich nicht mehr weiter. Und wollte deshalb mal einige Punkte mit euch durch gehen.
    1) Wass muss ich in meinem VS Projekt alles ändern damit die Anwendung auf die DB, welche auf einem (neuen) Server (und nicht mehr auf dem Rechner) abgelegt ist, zugreifen kann?
    2) Muss ich den Connectionstring ändern damit er statt auf LocalDB-daten auf einmal auf SQL-Daten zugreifen kann? Wenn ja, wie?3) Wie bekomme ich meine .MDF-DB auf den Firmenserver wo SQL Express drauf installiert ist? Reicht das, wenn ich die DB einfach dorthin kopiere? Oder geht das über sowas wie ein "Server-Management-Tool"?
    Wie ihr sehen könnt fehlen mir da noch einige Grundkenntnisse. Ich denke aber mal, dass diese kleine Hürden dank eurer Hilfe zu überwinden sein müssten.

    Vielen Dank im Voraus,
    Jeiss

    Hallo

    Jeiss schrieb:

    dank Code-First technologie

    Bedeutet das, das du mit EntityFramwork arbeitest? Wäre für andere vieleicht eine hilfreiche Info.

    Jeiss schrieb:

    Sie haben mir angeboten meine .MDF-Datei auf einen Firmenserver abzulegen auf dem eine SQL Express Edition drauf installiert ist.

    Meines wissens nach funktioniert das so nicht. LocalDB ist LocalDB und SQL Server ist SQL Server. Ist aber gar nicht notwendig.

    Jeiss schrieb:

    Wass muss ich in meinem VS Projekt alles ändern damit die Anwendung auf die DB, welche auf einem (neuen) Server (und nicht mehr auf dem Rechner) abgelegt ist, zugreifen kann?

    Wir kennen deine Anwendung nicht. Keine Ahnung aber....

    Jeiss schrieb:

    Muss ich den Connectionstring ändern damit er statt auf LocalDB-daten auf einmal auf SQL-Daten zugreifen kann? Wenn ja, wie?

    Ja, sonst weis Entity Framework ja nicht wo die DB liegt. Wie? Kommt wieder darauf an wie und wo du den Connectionstring setzt.

    Jeiss schrieb:

    Reicht das, wenn ich die DB einfach dorthin kopiere?

    Ne. Änderst du in EF den Connectionstring legt EF automatisch eine DB am Server an (sofern du die Rechte dazu bekommst).

    Dir fehlt nicht nur was Datenbanken betrifft, sondern auch was EF betrifft noch einiges an wissen und ich weis nicht ob das in dem Fall klappen wird, aber ein versuch ist es wert.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo Sascha,
    ich hab am Freitag leider die schlechte Nachricht von unserer IT-Abteilung bekommen, dass die mich jetzt doch nicht unterstützen wollen.
    Irgendwie zu riskant....
    Aber trotzdem möchte ich die Gelegenheit nutzen was dazu zu lernen.
    Ja du hast richtig vermutet, ich habe meine Anwendung mit code-first und EntityFramwork erstellt. Ich hab gar nicht geahnt, dass man mit code-first irgend eine andere Option als EntityFramework hat...
    Also ich hatte mir das ganz anders vorgestellt :(
    Ich hatte das so verstanden, dass die DB-Datei (also .MDF) von LocalDB ohne Problem von SQL unterstützt würde.
    Ich dachte, dass man beim Erstellen eines Projektes, aus Einfachheitsgründen, eine LocalDB-Datenbank anlegen würde und dann später wenn das Projekt fertig ist, beim "deployment" auf SQL wechseln würde. Hätte doch irgendwie Sinn gemacht, dass man sich bei der Erstellung einer Anwendung nicht schon Gedanken machen zu brauch wo die DB später mal hin kommen soll....
    Ok, ich möchte das gerne besser verstehen.
    Ich hab also mit VS2015 ein Projekt erstellt. Mit code-firs und EntityFramework hat VS dann beim ersten Durchlauf, aus meinen "Eigenschafts-Klassen" (kann man die so nennen...?) eine .MDF-Datei mit den entsprechenden Eigenschaften/Feldern erstellt.
    Wieso hat VS denn eine LocalDB-datei erstellt? Sind das default-Einstellungen?
    Hängt das davon ab ob SQL auf dem gleichen PC installiert ist, oder wovon hängt das ab?
    Ach ja, als ich fragte ob ich den connection-String ändern müsste um auf SQL zu wechseln. Da hab ich schon vermutet, dass ich da was ändern müsste. Aber ich hatte da mehr an die Syntaxe gedacht, nicht an den genauen String, sonst hätte ich den natürlich mit gepostet.

    Danke,
    Jeiss

    Hallo

    Jeiss schrieb:

    ich hab am Freitag leider die schlechte Nachricht von unserer IT-Abteilung bekommen

    Das ist schlecht. Ich kenne das, ich arbeite auch in einem größeren Konzern und habe gelernt solche Dinge vorher abzuklären und zwar immer schriftlich da es sonst gerne zu bösen überraschungen kommt.

    Jeiss schrieb:

    Ich hab gar nicht geahnt, dass man mit code-first irgend eine andere Option als EntityFramework hat...

    Anders rum. CodeFirst ist eine Art wie man EF verwenden kann. Es gibt noch ModelFirst und DatabaseFirst. Aber andere User fangen mit "CodeFirst" als einzigen Hinweis das es um EntityFramework geht sicherlich wenig an und können dir somit keine Hilfe anbieten da keiner weis um was es geht. Wollte ich nur anmerken. Zudem wäre immer interessant anzugeben welche Version du verwendest.

    Jeiss schrieb:

    Ich hatte das so verstanden, dass die DB-Datei (also .MDF) von LocalDB ohne Problem von SQL unterstützt würde.

    Das ist auch der Fall. Du solltest du dir unbedingt ansehen WAS genau EF ist und wie es funktioniert. Dein Vorhaben klappt so auch ohne Probleme und du kannst jederzeit von einer localDB zu einem SQL Server wechseln, es muss lediglich der Connectionstring angepasst werden. ABER, du denkst an dieser Stelle falsch. Du willst die Daten welche du (vermutlich manuell) angelegt hast migrieren. Das ist (oder sollte) nicht notwendig, dazu später mehr.

    Jeiss schrieb:

    Ok, ich möchte das gerne besser verstehen.

    Dann schau dir mal Lektüre über O/R Mapper an, denn genau das ist EF. Schau dir an was ein O/R Mapper macht und gehe dann zu EF im speziellen über. Alleine zu EF gibt es ganze Bücher.

    Jeiss schrieb:

    Wieso hat VS denn eine LocalDB-datei erstellt?

    Das zeigt mir das du dich nicht damit beschäftigt hast. Du hast EF ja einen ConnectionString angegeben, und du hast ein Model erstellt. Beim start der Anwendung hast du irgendwo den Code MeineContextInstanz.EnsureCreated(). Was EF nun macht ist nachzusehen (anhand des Connectionstrings) ob es eine DB gibt und wenn nicht diese Anhand deines Models zu erstellen. Und zwar als Abbild deines Models.
    Und schwups ist deine DB erstellt und du kannst damit arbeiten. Änderst du nun den ConnectionStrig auf eine SQL Server Connection geht das ganze von vorne los, weil es die DB an dem Ort nicht gibt.
    Aber... legst du die DB an dem Ort manuell an passiert genau garnix. Den EF sieht das es die DB gibt, legt also die Tabellen auch nicht an.

    Kommen wir zum nächsten. Seeding. Du solltest in deinem Programm beim Start prüfen ob die DB Daten enthält. Ist dies nicht der Fall schreibst du die Daten rein die deine APP benötigt.
    z.b. Settings oder gewisse Daten welche benötigt werden. Somit kann EF initial immer nach erstellen der DB die Daten reinschreiben denn zur Entwicklungszeiit ändert sich ja gerne mal auch das Model und dann muss/sollte die DB neu erstellt werden. Da willst du ja nicht wieder manuell alle Default daten eingeben, also lässt du das EF für dich machen.

    Kann in etwa so aussehen:

    VB.NET-Quellcode

    1. Using cxt as New MyContext()
    2. ctx.Database.EnsureCreated()
    3. if Not ctx.Settings.Any() Then
    4. 'Seed
    5. End If
    6. End Using


    Gehst du nun "Produktiv" und willst in der Firma einen SQL Server verwenden dann änderst du den Connectionstring (idealerweise ist der nicht HardCoded) und schwups hast du deine DB angelegt, alle anderen Daten werden dann ja eh von den Nutzern angeglegt.
    Stellt sich die Firma nun quer kannst du ja mit der IT eine andere Lösung ausarbeiten. Es gibt zig möglichkeiten. Wie z.b. einen SQL Server in Azure für kleines Geld.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hallo Sascha,
    ich bin dir sehr dankbar, dass du dich so
    ausführlich mit mir abgibst, ist wirklich nicht selbstverständlich. Ich weiß
    das zu schätzen.

    Ich hab deine Antwort mehrmals durchgelesen und
    werde das auch noch ein paarmal tun um wirklich alles da rausschöpfen zu
    können.

    Eins muss ich aber mal klarstellen. Ich hab in der Zwischenzeit einige Datensätze in dieser LocalDB-DB angesammelt. Und die
    möchte ich natürlich unbedingt behalten. Also ich weiß deshalb gar nicht ob der
    Begriff „Migration“ in meinem Fall zutrifft! Denn es geht mir nicht bloß darum eine
    DB-Struktur von LocalDB nach SQL zu migrieren, sondern auch um die Daten-Sätze.
    Ist doch bestimmt ein Unterschied. Aber trotzdem denke ich, ich verstehe dank deiner
    ausführlichen Erklärung jetzt besser was EF beim starten des Projektes alles macht.

    Also ganz stark vereinfacht: EF schaut nach ob die
    im Connectionstring angegebene DB bereits besteht, falls nicht wird sie nach
    den Vorgaben des code-first erstellt. So ungefähr. Egal ob Local oder auf einem
    Server.

    Leider liegst du mit der Annahme falsch, dass
    irgendwo in meinem Code ein „MeineContextInstanz.EnsureCreated()“ vorhanden
    sein muss.

    Ich komme irgendwie ohne aus…

    Die Konsequenzen davon sind natürlich nicht besonders
    positiv…

    Wollte mal ein bisschen „spielen“ und hab einfach
    mal meine DB aus dem Projekt rausgeholt…Und das Projekt frisch gestartet. Und
    natürlich hat EF, wie hast du es so lieb ausgedrückt: passiert genau garnix

    Soweit mal dazu. Aber wo findet man „MeineContextInstanz.EnsureCreated()“
    normalerweise in einem „klassischen“ code-first EF-Projekt vor?
    Beim Laden der Daten oder wo?

    Und noch was, „MeineContextInstanz.EnsureCreated()“
    hat nix mit „MeineContextInstanz .Database.CreateIfNotExists()“ zu tun? Oder?

    Also obwohl das auf der Arbeit nix mehr aus dem
    SQL-Server wird, will ich es aber ausprobieren…. Jetzt hab ich Blut geleckt! Ok,
    das muss jetzt keiner verstehen… Das ist wohl eher ein luxemburgischer Ausdruck
    sein.

    Ich gehe jetzt mal eine Woche lang Schifahren… Vielleicht
    ist dann auch der Kopf etwas klarer.

    Aber ich hab schon mal angefangen, auf einem älteren
    PC SQL-Server Express zu installieren und für „Remote-Zugriff“ zu konfigurieren.
    Und darauf möchte ich dann gerne probieren von meinem Projekt aus (ein anderer
    PC im gleichen Home-Netzwerk) zugreifen können.

    Und da könnte ich dann mal erforschen was EF so
    alles in punkto DB-Anlegen so draufhat. Aber das geht natürlich nur wenn das
    Forum mir weiterhin beisteht.

    Danke,

    Jeiss

    Hallo

    Jeiss schrieb:

    dass du dich so
    ausführlich mit mir abgibst, ist wirklich nicht selbstverständlich.

    Klar doch, dafür ist das Forum doch da oder. Wenn jemand will bin ich auch gewillt am Ball zu bleiben.

    Jeiss schrieb:

    Ich hab in der Zwischenzeit einige Datensätze in dieser LocalDB-DB angesammelt. Und die
    möchte ich natürlich unbedingt behalten. Also ich weiß deshalb gar nicht ob der
    Begriff „Migration“ in meinem Fall zutrifft!

    Richtig, Migration trifft nicht zu. Die Migration betrifft nur die Struktur der DB und deren Tabellen. Also das Datenbankschema.

    Wenn du die Datensätze behalten willst. (Da frage ich mich aber warum man die Zuhause wo eingibt. Da hätte ich mir vorher die DB am Server anlegen lassen (das hättest gleich gewusst ob dir die Firma das zulässt) und das gleich am "originalort" gemacht, aber gut jetzt gehts nicht mehr). Jetzt kannst du nur noch entweder (nachdem die neue DB existiert) per SQL Scripts die Daten rüberschaufeln oder per kleinem Konsolenprogramm welche dir die Daten neu reinschreib nachdem diese in der "alten" DB ausgelesen wurden. Geht einfach. In einer Konsolen-App einen Verweis auf deinen Context, den alten Connectionstring laden -> Daten lesen und im Ram lassen -> Connectionstring auf die "neue" DB ändern -> Daten in die neue aus dem Ram schreiben. Fertig.

    Jeiss schrieb:

    Und noch was, „MeineContextInstanz.EnsureCreated()“
    hat nix mit „MeineContextInstanz .Database.CreateIfNotExists()“ zu tun? Oder?

    Doch, doch. Verwendest du "noch" EF 6 und nicht EF Core? Siehste, deshalb ist es wichtig zu wissen mit was ein anderer genau Arbeitet. Kommt aber beides aufs selbe raus.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

Facebook
Telefonspende