Lokale SQL Compact Datenbank Import Dauert

  • VB.NET

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von diylab.

    Lokale SQL Compact Datenbank Import Dauert

    Heyho,

    ich importiere mittels eines SQL Command, welches im TableAdapter hinterlegt ist Daten in ein DataSet welches mit der Datenbank gekoppelt ist.

    SQL-Abfrage

    1. INSERT INTO [Personen] ([Title], [Given Name], [Middle Initial], [Surname], [City], [Mothers Maiden], [Birthday], [Kilograms], [Centimeters], [Gender]) VALUES (@Title, @Given_Name, @Middle_Initial, @Surname, @City, @Mothers_Maiden, @Birthday, @Kilograms, @Centimeters, @Gender)

    VB.NET-Quellcode

    1. personenTableAdapter.AddData(data(2), data(3), data(4), data(5), data(6), data(7), birthday, Convert.ToDouble(data(9)), Convert.ToInt32(data(10)), data(1))

    scheinbar ist dies allerdings nicht sonderlich effizient :thumbdown: , da es ziemlich lange dauert :D . Die Datenbank ist eine lokale SQL Compact Datei.
    Bisher habe ich nur beispiele für SQL Server gefunden, gespeicherte Prozeduren gibt es bei SQL Compact nicht.


    lg Nelethill

    Die Sache ist halt das das Programm auf normalen Heim Rechnern laufen soll und da kann ich ja nicht erwarten das der User einen SQL Server aufsetzt, mit dem dies weitaus schneller von staten gehen würde :D
    Und die Daten kommen nicht zwingender weiße aus einer Text Datei sie können auch vom Programm erzeugt werden. Wäre in diesem Fall eine XML datei effizienter? oder sind es für die zu viele Daten?

    ich würde sagen: Das ist das einfachste.
    Empfehle ich ja auch immer, wenn ich sage: DbProgrammierung ohne Datenbank.

    Nur dass ich einen Schritt weiter gehe, und die DB dann auch weglasse, wenn sie eh komplett geladen wird.

    Also das ist durchaus sinnvoll: Es ist einfach, und läuft am schnellsten.
    Und es macht auch nix, wenn da gleich 40000 Datensätze in den Speicher geladen sind - das mögen vlt. 5MB sein - Wayne interessierts?

    Anders rum zu sehen macht sinn: Wieso sollte man sich mit einer DB abquälen, und umständlich einen DbProvider involvieren, und höchst anfälligen Daten-Transfer-Code schreiben, wenn man den Kram auch direkt schnell mal einsaugen könnte?

    ErfinderDesRades schrieb:

    Also das ist durchaus sinnvoll: Es ist einfach, und läuft am schnellsten.
    Und es macht auch nix, wenn da gleich 40000 Datensätze in den Speicher geladen sind - das mögen vlt. 5MB sein - Wayne interessierts?


    Dann sind ja Datenbanken total überflüssig - danke für die Erleuchtung!
    Das werde ich gleich mal am Montag durchsetzen und unser RZ in Frankfurt abschalten lassen.
    Und alle 300 Prozeduren, Views und Trigger hauen wir auch gleich mit in die Tonne - wer braucht das schon? 8-) .

    LG,
    Bruno

    nein - in vielen Fällen sind Datenbanken nicht überflüssig.

    Aber in vielen anderen Fällen eben doch.


    Eure RZ in Frankfurt läuft vmtl. im MultiUser-Betrieb, mit Rechte-Verteilung, gespeicherten Prozeduren und weißgottwasnoch. Das sind natürlich alles Features, die man nicht eben lokal in den Speicher laden kann.

    Aber hier ist die Rede von einer popeligen lokalen SqlServerCe.

    ErfinderDesRades schrieb:

    Eure RZ in Frankfurt läuft vmtl. im MultiUser-Betrieb, mit Rechte-Verteilung, gespeicherten Prozeduren und weißgottwasnoch. Das sind natürlich alles Features, die man nicht eben lokal in den Speicher laden kann.

    Richtig !
    Und dies vermisse ich an Deinen vielen "ichpackdasDingindenSpeicher" Ausführungen/Tuts etc. ein bisschen.
    Nicht das Dein Modell für alle User zum Standard wird :D .

    LG,
    Bruno

    lass es doch Standard werden - genauer: "Standard-Ausgangspunkt"
    Sobald jemand MultiUser-Betrieb braucht, wird er darüber hinausgehen müssen.

    Der DatasetOnly-Ansatz ist eben kein Holzweg, wo man komplett umkehren muss und neu anfangen, sondern ein erweiterbarer Ansatz: wo man das gelernte komplett weiternutzt, zuzüglich der Erweiterungen.


    Ich kann meine Tuts auch nicht beliebig erweitern, ein Tut ist immer recht allgemein gehalten, und solche Dbs wie eure RZ ist immer eine Maßanfertigung und Einzelfall, und so umfangreich, dasses niemals in ein sinnvolles Tut ginge.
    Also diese Sachen wirst du immer vermissen in egal welchen Tutorials.

    Guck - in DBExtensions gehe ich etwas über den DatasetOnly-Ansatz hinaus, und zeige zumindest inkrementelle Befüllung - also was man braucht, wenn man nicht die ganze DB auf einmal laden will.
    Aber da kommt glaub kaum einer noch mit.

    Du kannst gern ein Tut schreiben, was in einer MySql-DB im MultiUser-Betrieb Parallelitäts-Konflikte löst, indem abgerufene Datensätze mit Timeout gelockt werden - haste Lust?
    Ich wüsste jmd. zu fragen, der vlt. sogar einen Hoster dafür bereitstellt.

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

    ErfinderDesRades schrieb:

    Du kannst gern ein Tut schreiben, was in einer MySql-DB im MultiUser-Betrieb Parallelitäts-Konflikte löst, indem abgerufene Datensätze mit Timeout gelockt werden - haste Lust?

    Wohl kaum.
    Ich könnte mich weder so gut Ausdrücken, wie es die meisten Schreiber solcher Artikel (inkl. Deiner Person) es können, noch hätte ich die Zeit dazu so genau zu schreiben, dass kein Müll entsteht.
    Aber Dein angesprochenes Thema ist eh OT.

    Wobei ich mir sicher bin, dass sich das Hauptproblem des TE ganz anders lösen lässt - wenn er uns nur die nötigen Infos zukommen ließe.
    Eine komplette DB - egal ob 3 oder 3 Milliarden Datensätze in einen anderen Container zu pumpen, halte ich trotzdem für suboptimal - da gibts sicher eine bessere Lösung.

    LG,
    Bruno

Facebook