DGV füllen ( Dynamisch )

  • C#

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

    DGV füllen ( Dynamisch )

    Hallo liebe Leser,

    ich habe mal eine kleine frage. Ich möchte gerne mit dem MySQL Connector arbeiten. Derzeitig hole ich die Daten aus der Databank wie folgt

    C#-Quellcode

    1. public List<string>[] Select(string Query)
    2. {
    3. string query = Query;
    5. List<string>[] list = new List<string>[5];
    6. list[0] = new List<string>();
    7. list[1] = new List<string>();
    8. list[2] = new List<string>();
    9. list[3] = new List<string>();
    10. list[4] = new List<string>();
    12. if (this.OpenConnection() == true)
    13. {
    14. MySqlCommand cmd = new MySqlCommand(query, connection);
    15. MySqlDataReader dataReader = cmd.ExecuteReader();
    17. while (dataReader.Read())
    18. {
    19. list[0].Add(dataReader["ID_User"] + "");
    20. list[1].Add(dataReader["Benutzername"] + "");
    21. list[2].Add(dataReader["Passwort"] + "");
    22. list[3].Add(dataReader["LastLogin"] + "");
    23. list[4].Add(dataReader["IP-Adresse"] + "");
    24. }
    26. dataReader.Close();
    28. this.CloseConnection();
    30. return list;
    31. }
    32. else
    33. {
    34. return list;
    35. }
    36. }


    Nun wollte ich mal fragen, was ihr dazu sagt, wie man das Ganze dynamisch macht. Ich weiß, dass man mit dem Connector einfacher an die Daten kommt, aber dann übernimmt das DGV die Spaltennamen, wie sie in der Tabelle gespeichert sind. Das möchte ich aber nicht. Würdet ihr das Ganze mit Übergabe Parametern machen, sodass man bei jeder anderen abfrage die Spaltennamen als Übergabe Parameter angeben muss?
    ---
    Außerdem wollte ich frage, ob einer vielleicht ein Tutorial da hat, wo erklärt wird wie man eine Live Suche im DGV machen kann..

    MFG

    Marcello
    P.S. Falls ein vorhandes Tutorial da ist oder das Thema schon bearbeitet wurde, bitte ich um den Link.

    da bleibt eine frage bei mir Offen. Würdest du die Datenbank direkt an das DGV Binden bzw. die Connection über Visual Studio ( C# ) aufbauen oder über den MySQL Connector
    Like ( eben schnell Copy&Past // Quelle : Connection a MYSQL Table to DGV )

    C#-Quellcode

    1. ​
    2. if (this.OpenConnection() == true)
    3. {
    4. mySqlDataAdapter = new MySqlDataAdapter("select * from composers", connection);
    5. DataSet DS = new DataSet();
    6. mySqlDataAdapter.Fill(DS);
    7. dataGridView1.DataSource = DS.Tables[0];
    9. //close connection
    10. this.CloseConnection();
    11. }

    Wenn ich es so machen würde, kann ich schon vorher die Spalten im DGV festlegen und er pack nur noch die Daten in die Spalten rein ? Ich meine eigentlich als ich es letzten probiert hatte, hatte er meine erstellen gelöscht und die von der Tabelle genommen.. :D

    man kann keine DB direkt an ein DGV binden. Wer sowas erzählt, weiß nicht, was Databinding ist.

    Marcello schrieb:

    Wenn ich es so machen würde, kann ich schon vorher die Spalten im DGV festlegen und er pack nur noch die Daten in die Spalten rein ?
    Nein, denn das ist kein typisiertes Dataset, was da in zeile#5 erzeugt wird.

    erzeuge dir ein typisiertes Dataset mittm Connector, und befülle es mit den TableAdaptern, die der Connector ebenfalls generiert.
    Guck dir das gegebene Tutorial doch einfach mal an, da mache ich glaub ganz deutlich, dass man mit untypisierten Datasets nur Müll produzieren kann.
    (Oder hast du etwa schon - wie konnte dir dieser Punkt dann entgehen?)

    Nochmal: Die DGV-Spalten im Designer designen ist nur bei Bindung an die typisierten Datatables eines typisierten Datasets möglich. Untypisierte Datasets enthalten untypisierte DataTables, und damit ist das nicht möglich.

    ​Lösung gefunden.


    Erklärst du uns auch was du nun gemacht hast?

    ​Zwar anderes als du erklärkst, aber nun hab ich es so wie ich es wollte


    Nachdem typisierte Datasets die einzige wirklich sinnvolle Lösung sind würde ich dir noch einmal ans Herz legen das du das noch einmal überdenkst und die Videos von EdR noch einmal ansiehst. Alles was mit untypisierten Datasets geht geht auch mit typisierten und das auch noch wesentlich sicherer.

    Wenn du jetzt mit untypisierten Datasets arbeitest "nur weil es jetzt funktioniert" bedeutet das nicht das du es richtig machst und selbst wenn das bei diesem Projekt noch gut gehen sollte lernst du dir doch etwas falsches ein und wirst mit dieser Methode bei einem etwas größerem Projekt große Probleme bekommen die sich alle samt mit typisierten Datasets hätten vermeiden lassen.

    Meine Lösung:

    C#-Quellcode

    1. MySqlCommand myCommand = new MySqlCommand("select * from tbl_user", connection);
    2. MySqlDataAdapter myDA = new MySqlDataAdapter(myCommand);
    3. DataSet myDS = new DataSet();
    4. myDA.Fill(myDS,"tbl_user");
    6. myDS.Tables["tbl_user"].Columns["ID_User"].ColumnName = "ID";
    7. myDS.Tables["tbl_user"].Columns["IP-Adresse"].ColumnName = "IP-Addr";
    9. dataGridView1.DataSource = myDS.Tables["tbl_user"];


    Ob sie jetzt richtig ist, weiß ich leider nicht.

    Das was du hier produzierst entspricht genau dem was ich in einem Vorpost als falsch und EdR als Müll bezeichnen


    Sorry ich verstehe aber nicht was er in den 4 Videos von mir möchte.. Ich sehe nur, dass er ein DataSet anlegt und dort Tabellen sozusagen erzeugt und wie man Spalten im DGV macht... Was bringt es mir, wenn ich schon Tabellen habe

    Marcello schrieb:

    Was bringt es mir, wenn ich schon Tabellen habe
    Tja, wie's aussieht, ists "um dich geschehen".
    Du hast bereits angefangen mit Datenverarbeitung ohne Databinding, ohne DataAdapter, ohne typisiertes Dataset, ohne Kenntnisse von Datenmodellierung, und da wirst du wohl fortfahren.
    Was derzeit noch vergleichsweise einfach aussieht - vlt. 40 Zeilen, um die Tabelle anzuzeigen - wird sich zu unübersehbaren Code-Wüsten ausweiten, wenn du mal paar mehr Tabellen hast, und auch mal abspeichern willst.

    Entgehen tut dir dabei die Änderungsverfolgung des Datasets und die möglichkeit, die Oberfläche databinding-orientiert in dafür vorgesehenen Designern zu gestalten.
    Weiters ist das untypisierte Coden extrem unsicher, denn jeder Wert muss per String-Schlüssel abgerufen werden, und ist dann nur vom Typ Object, und um was damit zu tun, muss er erstmal richtig gecastet werden.

    Aber vlt. kommst du ja mal wieder drauf zurück, wenn du vor größeren Problemen stehst.

    ​Tja, wie's aussieht, ists "um dich geschehen".Du hast bereits angefangen mit Datenverarbeitung ohne Databinding, ohne DataAdapter, ohne typisiertes Dataset, ohne Kenntnisse von Datenmodellierung, und da wirst du wohl fortfahren.Was derzeit noch vergleichsweise einfach aussieht - vlt. 40 Zeilen, um die Tabelle anzuzeigen - wird sich zu unübersehbaren Code-Wüsten ausweiten, wenn du mal paar mehr Tabellen hast, und auch mal abspeichern willst.Entgehen tut dir dabei die Änderungsverfolgung des Datasets und die möglichkeit, die Oberfläche databinding-orientiert in dafür vorgesehenen Designern zu gestalten.Weiters ist das untypisierte Coden extrem unsicher, denn jeder Wert muss per String-Schlüssel abgerufen werden, und ist dann nur vom Typ Object, und um was damit zu tun, muss er erstmal richtig gecastet werden.Aber vlt. kommst du ja mal wieder drauf zurück, wenn du vor größeren Problemen stehst.


    Naja ich kann das schon verstehen... auf den ersten Blick können die ganzen Informationen um typisierte Datasets schon riesig sein ... und warum soll ich das alles lernen wenn ich ein einfaches SQL Statement abgeben und das Ergebniss in ein DGV packen kann... und das mit 7 zeilen code..

    Die Antwort ist einfach:

    Stell dir mal vor du willst Daten in dem DGV vom Benutzer ändern lassen. Dann müsstest du jede Änderung die der Benutzer machen könnte vorhersehen und in ein SQL Kommando umwandeln. Und wenn du dabei nicht höllisch aufpasst hast du einen Fehler im System den du nur ganz schwer wieder finden kannst. Denn das von dir generierte Kommando ist für Visual Studio ein String ... nicht mehr als eine einfache Zeichenfolge.

    Jetzt stell dir mal vor du könntest ein DGV füllen ohne Tabellen von Hand erstellen zu müssen. Du könntest die Tabellennamen einfach mitladen lassen außerdem natürlich die ganzen Daten und das mit nur einer einzigen Zeile Code. Du musst nichtmal SQL dafür verstehen.

    Und dann stell dir vor du könntest auf knopfdruck alle änderungen die in einem DGV gemacht wurden in die Datenbank zurück speichern. egal ob dabei neue Zeilen angelegt oder der Inhalt der Zellen verändert wurde. und auch das ohne einen SQL Befehl kennen zu müssen und wieder mit nur einer Zeile Code.

    Der clou an der Sache ist das nebenbei alle Statements die an die Datenbank gehen immer korrekt sind. Du musst dich um die Syntax überhaupt nicht kümmern und kannst dich auf dein eigentliches Projekt konzentrierten. Außerdem sichert sich das ganze auch gleich in Echtzeit gegen Falscheingaben seitens des Benutzers ab. Denn wenn in einer Zelle eine Zahl erwartet wird und der user tippt dort einen Buchstaben und will die Zelle verlassen wird automatisch geprüft ob der Datentyp überhaupt so in die Datenbank geschrieben werden kann und der Benutzer bekommt prompt eine Meldung.

    Wenn du das toll findest... dann willkommen in der Welt der typisierten Datasets .... und ich habe nur einen Bruchteil von dem erklärt das möglich ist...

    @Cell du sprichst es einfach aus was ich suche.

    Jetzt meine frage. Ich habe damals ( 2 Jahre her ) mit einem DGV gearbeitet, dort habe ich aber nur Datan aus einem HTTPWebRequest ins DGV geladen.
    Nun wollte ich mit Datenbanken arbeiten. In deinem Betrag habe ich nählich erstmal verstanden was ganze Zeit mit typisierten Datasets gemeint ist.
    Wollte mal nach fragen, ob es ein TUT gibt ( denke mal von EDR ) wo man von Anfang an mit DataSet usw usw anfängt.

    Marcello schrieb:

    ob es ein TUT gibt ( denke mal von EDR ) wo man von Anfang an mit DataSet usw usw anfängt.
    na aber vier Views-Videos ist doch dieses Tut!
    In Film1 wird doch ein typisiertes Dataset geschaffen, und alles weitere wird darauf aufgebaut.
    Wenn du den MySqlConnector hast, dann kannst du dir ein typDataset auch aus deiner MySql-Datenbank generieren lassen.

    Also auf "Datenbank in 10 Minuten" auf erfinderdesrades.unitweb.de/Pr…r/Downloadpage/index.html wird eingangs auch gezeigt wie, und wie einfach das ist.
    Allerdings am Beispiel von Access.
    Aber wenn der MySqlConnector richtig funktioniert (und das ist immer das Problem), dann geht das exakt ebenso.

    Funktionieren die Links, und findest du das animierte Tutorial darin?

    @ErfinderDesRades ich werde mich morgen mal auf meine vier Sachen setzten und mir alles ganz genau anschauen und hoffe, dass ich es verstehen werde und bald meine Lösung ( die hoffentlich dann richtig ist ) prästentieren zu drüfen :) !!!

    @ErfinderDesRades ich werde mich morgen mal auf meine vier Sachen setzten und mir alles ganz genau anschauen und hoffe, dass ich es verstehen werde und bald meine Lösung ( die hoffentlich dann richtig ist ) prästentieren zu drüfen !!!


    Er wurde bekehrt 8o

    ​Aber wenn der MySqlConnector richtig funktioniert (und das ist immer das Problem), dann geht das exakt ebenso.


    Wenn der Connector korrekt installiert wurde funktioniert er genau so wie alle anderen auch wunderbar. Ich habe bereits mehrmals mit Mysql Datenbanken und VB.Net gearbeitet und die Vorgehensweise ist genau gleich wie zb beim MSSql

    Ich speichere alle Änderungen (Löschen, Änderungen, neue Datensätze) auch mit wenig Codezeilen (sprich: mit der Update-Method, also DataAdapter) und benutze dabei das Designer und typisierte Datasets nicht. Weil ich keine unnötige Codes und Objekte haben möchte, weil ich wegen einer Änderung in der Datenbankstruktur keine Sicherheitskopien machen und darauf hoffen will, dass es nach der Änderung kein Fehler auftauchen werden, die ich nur mit Neugenerierung des Datasets, etc. bereinigen kann.

    ErfinderDesRades schrieb:

    Weiters ist das untypisierte Coden extrem unsicher, denn jeder Wert muss per String-Schlüssel abgerufen werden, und ist dann nur vom Typ Object, und um was damit zu tun, muss er erstmal richtig gecastet werden.


    Macht auch der vom Designer generierte Code so.

    Cell schrieb:

    Denn das von dir generierte Kommando ist für Visual Studio ein String ... nicht mehr als eine einfache Zeichenfolge.


    Ist auch beim typ. Datasets nicht anders.

    Cell schrieb:

    Jetzt stell dir mal vor du könntest ein DGV füllen ohne Tabellen von Hand erstellen zu müssen. Du könntest die Tabellennamen einfach mitladen lassen außerdem natürlich die ganzen Daten und das mit nur einer einzigen Zeile Code.


    Man muss doch keine Tabellen von Hand erstellen. Und ja, mit einer einzigen Zeile Code, was der User selber eintippt, aber im Hintergrund ist alles ganz schön lang im Designer-File codiert.

    Cell schrieb:

    Du musst nichtmal SQL dafür verstehen.


    Ja, typ. Dataset mit Designerunterstützung verspricht schnell Erfolg. Und so werden Programme erstellt und Leute sich Programmierer nennen, die letztendlich nicht wissen, was das Programm im Hintergrund macht, wie sie Validierung machen, was es SQL auf sich hat, etc. und sie sagen dann: "schaut mal, es geht nur mit einer einzigen Zeile Code. Wie toll..."

    Dem dies gut ist, soll sich der Möglichkeit bedienen.

    Hier im Forum wird die Benutzung des typ. Datasets über alles gestellt und bis zur Unendlichkeit gelobt und dabei alles andere als Müll gezeichnet. EDR und Co. sollten sich der Sache bewusst sein, dass alle Lösung Vor- und Nachteile haben und nicht nur die eine die richtige ist.

    Und schlussendlich:



    Wie passt das in die Welt von EDR??

    Du stellst sehr richtig fest, dass der Designer es ist, der bei typisierten Datasets den riskanten Code generiert.
    Damit hast du den einen (Riesen-)Vorzug davon bereits benannt: denn anders als der Programmierer macht der Designer dabei keine Fehler. Der Sinn des Designers ist - neben Wysiwyg - trivialen, untypisierten und riskanten Code durch die generierten Klassen vom Programmierer weggzukapseln, sodass dieser typisiert programmieren kann.
    Weitere Vorzüge sind, dass man Databinding nun ebenfalls designen kann, im Form-Designer also Wysiwyg - das "Visual" am VisualStudio steht dir nun auch bei databinding-getriebener Oberflächengestaltung zur Verfügung.

    Und die Vorgehensweise hält auch ein umfangreiches Instrumentarium zur Validierung bereit, und BusinessLogik zu hinterlegen und so Sachen.

    vb_fan schrieb:

    dass alle Lösung Vor- und Nachteile haben und nicht nur die eine die richtige ist.
    Tja, das mag ich an Programmierung: Anders als im richtigen Leben kann man hier oft recht klar zwischen besserer und schlechterer Lösung unterscheiden: Man kann die Anforderungen definieren, und wenn 2 Lösungen dieselben Anforderungen bedienen, ist fast immer eine besser.
    Und als Programmierer hat man keinen Grund, die schlechtere zu wählen - folglich kann man sich (wie ich zB) durchaus berechtigterweise gelegentlich darin versteigen, schlechtere Lösungen als "falsch" zu bezeichnen.
    "Falsch" ist nur ein anderer Ausdruck für "diese Lösung ist schlechter".
    Diese Denke ist stark angelehnt an den philosophischen Begriff "Ockhams Messer".
    Und ich sag solch ja niemals nur so hin (glaub ich jdfs), sondern ich begründe das, wenn ich solch sage.

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

Facebook
Telefonspende