Auf MSSQL DB zugreifen

  • VB.NET

Es gibt 80 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Nils_Kr schrieb:

    Das sollte nicht länger als wenige Millisekunden dauern und da ist es doch recht unwahrscheinlich, dass zwei Personen genau gleichzeitig auf speichern drücken.
    Du unterschätzt den Zufall ;)
    Wenn es fachlich in Ordnung ist, dass zwei konkurrierende Datensätze drin stehen, kannst du den INSERT ein paar mal loopen lassen, bevor du einen Fehler wirfst.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    ich tu mich nach wie vor schwer damit leicht verständliche Infos zu finden. Um alle Daten auf einmal in ein DataSet zu laden hab ich folgende Funktion gefunden:

    VB.NET-Quellcode

    1. connection.Open()
    2. command = New SqlCommand(sql, connection)
    3. adapter.SelectCommand = command
    4. adapter.Fill(DataSet1)
    5. adapter.Dispose()
    6. command.Dispose()
    7. connection.Close()


    Macht das Sinn und wenn ja, gibt es eine genauso einfache Funktion um alle Daten aus dem DataSet auf einmal auf den Server zu schreiben?

    E:Der Compiler hat übrigens kein Problem mit dem Quelltext. Momentan ist der String sql in SqlCommand allerdings noch ="Your SqlStatement here" Was muss da rein?


    Ps: Ich hab mir das MainForm vom DBGenerator ausführlich angeguckt aber nix gefunden, dass mir danach aussieht, als ob in oder aus einem DataSet schreiben würde.
    Es ist übrigens anderweitig ausgeschlossen, dass mehrere Pcs auf einmal versuchen ein DataSet mit dem SQLServer zu synchronisieren, das ist hierbei also kein Problem.
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Nils_Kr“ ()

    was soll ich sagen? DbExtensions hab ich dir ja schon vor zig Posts empfohlen, da ist eine Extension drin, die geht so:

    VB.NET-Quellcode

    1. myDataset.Fill
    und das Dataset ist komplett befüllt.
    Es sind weitere Extensions drin, mit denen man auch einzelne Tabellen befüllen kann, auch mit selektiver Befüllung, und auch gefilterte Befüllung, aber erstmal voll machen geht wie gezeigt.

    auch, und eine annere Extension ist auch drin:

    VB.NET-Quellcode

    1. myDataset.Save(me)
    und gespeichert ist.

    Also imo einfacher geht's nicht. Wie man die DbExtensions "anschließt", oder wie man ühaupt eine Datenbank so aufsetzt, dass sie zum Dataset passt, ist ja im Film zu DbGenerator gezeigt.

    hmm, den link auf DBextensions innerhalb des DBgen Posts hatte ich einfach übersehen. Egal, jetzt hab ich Material, dass sich genau mit der Problematik befasst.

    Vertraust du dem DataSetDesigner eigentlich restlos? Mein Onkel betreut große Projekte bei Siemens und der meint, dass der Designer manchmal etwas unberechenbar
    reagiert und daher gerne für Probleme sorgt.
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Also gelegentlich verhaspelt er sich. Dann failt das Code-Generieren, und es entstehen mehrere Hundert Fehler.
    Lösung: die Dataset.Designer.VB komplett ausschneiden, wieder einfügen, neu kompilieren.
    Falls das nicht hilft: die Designer.vb. löschen, und im Designer nur ein bischen eine Tabelle verschieben, sodass der Code neu generiert wird.
    Also finde ich noch einfach zu handeln, weil wenner sich verhaspelt, sind das typischerweise gleich 102 Fehler (offenbar das Error-Report-Maximum) - da weiß ich gleich Bescheid.

    Nerviger ist ein Bug der Grafik-Darstellung: Wenn man schön seine Tabellen designed hat und angeordnet, dass die Relationen nicht gar zu wirr kreuz und quer verlaufen, und man öffnet das am nächsten Morgen neu, dann hat er die Tabellen-Darstellungen oft völlig bescheuert neu positioniert.
    Also alles funzt noch wies soll, aber wenn man für einen Überblick ins Dataset gucken will, muss man das Knäuel oft wieder neu entwirren.
    Einmal hat mich das so genervt, da hab ichs entwirrt, Screenshot gemacht, und gucke jetzt im Screenshot die Struktur nach.

    Also die Bugs sind bisserl nervig, aber wirklich kaputt gegangen ist mir noch nix.

    Ich hab jetzt mal versucht die DB-Extensions in mein Projekt einzugliedern. Dabei hab ich folgende Warnmeldung erhalten: "Verweise zwischen Projekten, die für verschiedene Laufzeiten oder .NET Framework-Profile vorgesehen sind, werden nicht unterstützt. Der Verweis wird als Dateiassmblyverweis behandelt. [...]". Makiert ist die Meldung mit einem blauen i.

    Ist die Meldung irrelevant, oder wird die Funktionalität tatsächlich beeinflusst?

    E: Hab jetzt selbst herausgefunden, dass die Frameworkversion übereinstimmen muss. Wenn man die DB-Extensions auf 4.5 upgraded wird man mit Fehlermeldungen überhäuft. Mein Programm hat das
    Downgrade auf 4.0 allerdings Fehlermeldungsfrei überstanden. Nur finde ich es etwas suboptimal, dass die Anwendung erstmal nicht mehr mit dem aktuellen Framework laufen kann.

    E2: Sobald ich die DBExtensions aus AllTogether rauskopiere werden beim ersten öffnen 102 Fehler angezeigt. Das ist irgendwie nicht zielführend.

    Gibt es jemanden, der mit dabei helfen kann ohne die Extensions eine DataTable mit einem MSSQL-Server zu snychronisieren? Mit dem Server kann ich mich inzwischen verbinden.
    Mir fehlt nur ein Lese- und ein Schreibbefehl, der jeweils den Server mit dem Programm abgleicht.
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Nils_Kr“ ()

    komisch. Nach meinen Versuchen müssen Hilfs-Projekte ein niedrigeres oder gleiches Framework nutzen wie das Haupt-Projekt.
    Folglich gehe ich davon aus, dass du beim Zusammenbinden was falsch gemacht hast.

    Also die Haupt verweist auf die Helpers, nicht umgekehrt.
    Und dann geht das.

    Oder mach ein Sample, was den Fehler reproduziert, und hängs an, aber ohne Binaries.

    Ich hab mir dein Video zum einbinden der Helpers angeguckt und die Schritte 1zu1 befolgt. Ich hab noch eine andere Extension in mein Programm integriert und die läuft problemlos.
    Kann man die DB-Extensions überhaupt ohne die anderen Helpers benutzen?
    Hier mal ein Ausschnitt der Fehler:



    Inzwischen frage ich mich halt ob es nicht leichter ist, die Synchronisierung manuell zu machen, anstatt die DBExtensions zum laufen zu bringen :huh:

    E: Ich hab jetzt mal testweise die GeneralHelpers und die WinFormHelpers zuerst importiert. Bei beiden null Fehlermeldungen, dann die DBExtensions und es sind 102 Fehler. Scheinbar schaltet sich Option strict beim importieren automatisch ein. Falls ich es dann abschalte verscwhinden die Fehler. Aber das ist doch kein gutes Zeichen, wenn man Option strict abschalten muss oder? :huh:
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Nils_Kr“ ()

    nein, DbExtensions nutzt intensiv die WinForms und die GeneralHelpers.

    Das ist quasi eine Schichtenarchitektur, vom Einfachen, allgemeingültigen (general) zum Anspruchsvollen, spezialisierten (DB).

    Eine ObjectBrowser-Suche inne Sample-Solution hätte dir übrigens aufgezeigt, wo die als fehlend benannten Begriffe zu finden gewesen wären.

    bei mir tun die mit Strict On.
    Ich würd dir empfehlen, nimm da keine Veränderungen vor, sondern orientiere dich am video und an den Beispiel-Codes, die zeigen doch, wie's geht.

    Wenn das nicht so funzt, wies ist, dann benutzt du es falsch, und wenn du dann den Code änderst oder so Grundeinstellungen wie Option Strict, machst dus nur schlimmer.

    Aber ich kann dir auch eben ein Beispiel basteln, wenn dir das nicht zu doof ist.
    Weil das Beispiel wird nur daraus bestehen, in einem beliebigen dortigen CodeSample das Framework der Haupt-Anwendung hochzusetzen.

    Und noch einmal: Wenn du nicht alle Helpers eingebunden hat, dann funzt das nicht - dann hast du aber auch nicht die Anleitung 1:1 befolgt.

    WinFormHelpers verweist auf (braucht) Generalhelpers, DbExtensions verweist auf WinformHelpers und GeneralHelpers.
    Und das Hauptprojekt verweist auf alle 3 Helpers.

    Wie gesagt: Es sind quasi Schichten, und die höheren Schichten haben keinen Bestand ohne die niederen.

    Wobei -

    Nils_Kr schrieb:

    Ich hab mir dein Video zum einbinden der Helpers angeguckt und die Schritte 1zu1 befolgt.
    Das Video zum DbGenerator ist kein Video zum Einbinden der Helpers. Es ist ein Video zur Migration einer DatasetOnly-Anwendung auf eine Datenbank-Anwendung.
    Dass die Helpers (richtig!) eingebunden sind, ist im Video vorrausgesetzt.

    Zum Einbinden von Assemblies gugge die Filmle auf Video: HelperProjekt einbinden

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    was willst du probieren?
    Wenn du die PersonBerufApp.zip vom DbGenerator-Thread downloadest, entpackst, im VS öffnest und startest - läuft das oder welcher Fehler kommt?

    Ich habs grade probiert, und es kommt der Fehler, dass der Pfad zur DB nicht stimmt, was ja wohl logisch ist, den muss man anpassen auf die SqlCe_FW4.sdf an dem Ort, wo sie hin entpackt wurde.

    Ich hab grad die PersonBerufApp ausprobiert. Mit angepasstem Verzeichnis startet läuft das Programm ohne Fehlermeldungen. Wenn ich aber die DBExtensions in mein Projekt importiere kommt es zu
    den Fehlermeldungen. Ich hab das Ganze jetzt schon ca. 15 mal probiert und die Fehler sind immer da. Wie gesagt, wenn ich andere Sachen in mein Projekt importiere laufen diese ohne Probleme,
    z.B. die GenerallHelpers oder PDFsharp, was ich recht ausführlich nutze.

    Ich geh davon aus, dass das irgendein Fehler vom Compiler oder so ist, weil die markierten Fehler auch ziemlich komisch sind, aber ich kenn mich VS nicht gut genug aus um den Fehler zu finden.
    Ich möchte mein Programm hier auch nicht hochladen, weil inzwischen einige sensible Daten drinne stehen und ich nicht weiss, ob ich die restlos entfernen kann.

    Von daher die Frage, ob mir nicht jemand auch ohne die DBExtensions helfen kann. Ich brauche erstmal nur einen SaveTo und einen LoadFrom-Befehl, wobei die Verbindung bereits besteht. In den Extensions
    müssen die Befehle garantiert auch drinne stehen, aber ich finde diese gerade leider nicht.
    Option strict = on

    If it's stupid and it works it ain't stupid.

    du meinst also, eine passende Db händisch aufzusetzen, und alle Zugriffs-Routinen selbst zu coden wird einfacher werden, als den Fehler zu beseitigen, der scheinbar beim Einbinden der DbExtensions vorliegt?
    Das ist sehr sehr viel individuelle Arbeit, mit DataAdaptern, DbCommands, DbParametern, CommandBuildern, und die Tabellen sind auch in der richtigen Reihenfolge fürs Einlesen einzulesen, und in der anderen richtigen Reihenfolge fürs Rückspeichern rückzuspeichern.
    Und viele naheliegende Vorgehensweisen - wie DataReader, oder das Einfrickeln von Daten in den Commandtext - sind dabei zu meiden wie die Pest, also da sitzst du gerne mal paar Monate dran, und am Ende isses eine enorme Menge Code, höchstwahrscheinlich verbugt und unwartbar.

    Du kannst eine Sample-Solution anhängen, die die Fehler reproduziert - vlt. sehe ich auf den ersten Blick den Einbindungs-Fehler.
    Das Helper-Einbinden-Video hast du genau studiert, und alle dort angerissenen Fehlerquellen bei dir gecheckt?
    Wie gesagt: Es kann nicht sein, dass mein Projekt bei dir läuft, deines aber nicht. Denn wenn meins läuft, beweist das, dass es auch auf deinem System möglich ist, erfolgreich einzubinden.
    Und darum sollteste dich kümmern statt jetzt einen Riesen-Workaround anzufangen.

    hm ok, bis jetzt klang es eher so, dass das mit der DB-Verwaltung eher easy ist. Ich hab es jetzt mal andersherum versucht. Erst die DB-Extensions geöffnet, dann mein Projekt importiert und
    dieses dann als Standartprojekt gesetzt. Jetzt hab ich die Helpers in meinem Projekt und zwar ohne Fehlermeldungen mit scheinbar funktionierendem Verweis 8o
    Beides übrigens auf NET4.5.

    Jetzt werd ich mir nochmal gründlich alles zu den DBExtensions durchlesen und dann wahrscheinlich nochmal jede Menge Fragen stellen, bis wirklich alles läuft. :D
    Option strict = on

    If it's stupid and it works it ain't stupid.

    ah - evtl. hast du das Projekt eingebunden, und nur nicht kompiliert!

    Nils_Kr schrieb:

    klang es eher so, dass das mit der DB-Verwaltung eher easy ist
    wer will dir sowas weismachen?
    Wenn das easy wäre, warum rate ich dann immer, das auf später zu vertagen?
    Mitte DbExtensions ists auch so easy wie möglich, dafür hab ich mir in > 5000 Zeilen Code alle erdenkliche Mühe gegeben ;)

    Kompilierung funktioniert, keine Fehlermeldungen, das ist für mich schonmal ein großer Erfolg.

    Ich hab mir grad das Video vom DBGenerator angeguckt. Ich hab leider die Datenbank nicht in Dateiform vorhanden von daher kann ich das Programm
    nicht ohne weiteres benutzen. Ich kann allerdings mit dem MS Server Management Studio manuell Tabellen anlegen, das sollte dann auch passen,
    wenn diese dann mit meinem DataSet übereinstimmen oder?

    VB.NET-Quellcode

    1. Dim adp = New DatasetAdapter( _
    2. SqlServerCe.SqlCeProviderFactory.Instance, _
    3. "Server=**********\************;" _
    4. & "database=**********; " _
    5. & "user id=***************;" _
    6. & "password=**********", _
    7. Data.ConflictOption.OverwriteChanges)


    Mit diesem String hab ich bisher auf den Server zugegriffen. Allerdings mag der Compiler den Begriff Server nicht. Wie muss ich denn den String anpassen, dass das funktioniert?
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nils_Kr“ ()

Facebook
Telefonspende