Spaltennamen aus GridView auslesen und in SQL-Anweisung übergeben

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    Spaltennamen aus GridView auslesen und in SQL-Anweisung übergeben

    Hallo liebes Forum.

    Ich bin recht neu in der VB-Programmierung und wollte mir aus einem Tool, welches ich in Excel (VBA) Programmiert habe mal eine "richtige" Anwendung bauen. Bevor ich allerdings durchstarte, möchte ich mir eine Datenbankverwaltung
    erstellen, damit ich es später einfacher habe. Als Datenbanken nutze ich .accdb-Dateien, da ich dort zur Not auch mal mit Access draufgehen und diese bearbeiten kann.

    Jetzt ist es so, dass meine Datenbanken bzw. die Tabellen darin unterschiedlich aufgebaut sein werden. Es wird also eine unterschiedliche Anzahl an Spalten und auch unterschiedliche Typen der Spalten geben.
    Ich kann einzelne Zellen innerhalb eines DataGridViews bearbeiten, diese Änderungen werden auch erfolgreich an die Datenbank übergeben. Auch das Löschen von kompletten Zeilen wird an die Datenbank übergeben.

    Wie sieht es aber mit dem Erstellen kompletter Zeilen aus?
    Hier stehe ich vor meinem Problem. Eine Überlegung von mir ist daher:

    Gibt es eine Möglichkeit, die Spalten samt Namen aus dem DataGridView auszulesen und diese dann einzeln an eine SQL-Abfrage zu übergeben? Geht sicherlich, ich habe aber keine Idee wie.
    Der SQL-String lautet ja dann in etwa so:

    sql = "INSERT INTO tabelle (spalte) VALUES (wert) WHERE ID=id; (das klappt auch so für einzelne Zellen)

    Meine vorstellung:
    sql = "INSERT INTO tabelle (spalte1 aus DGV, spalte2 aus DGV, etc..) VALUES (wert1 aus DGV, wert2 aus DGV, etc..)

    wie gehe ich das am sinnvollsten an, ohne dass ich mir für jede unterschiedliche Datenbank eine Form mit entsprechender anzahl an Textfeldern und damit verbundenden anderen SQL-String bauen muss?
    Ich möchte gerne die Editierfunktion des DataGridViews beibehalten und benutzen - ist für mich komfortabler als das über separate Textboxen zu lösen.

    LG und einen schönen Sonntag zu Hause gewünscht :)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

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

    Hallo und Willkommen!

    Das zweit-einfachste ist, sich vom VisualStudio Datenklassen und Datenbank-Zugriff generieren zu lassen.
    Gugge etwa typisierter Db-Zugriff mit Connectoren

    Das wirklich einfachste ist, anstatt eine Datenbank zu designen und Datenklassen und Connectivität zu generieren.
    die Datenklassen direkt designen, und anstatt mittels Connectivität in eine Datenbank zu frickeln einfach so auf Platte schreiben und laden.
    Daten laden, speichern, verarbeiten - einfachste Variante
    Den Umgang mit den Datenklassen muss man sowieso erlernen, und es erlernt sich wesentlich leichter, wenn man nicht auch noch ständig mit DB-Connectivität rumhampeln muss.
    Wenn letztere unabdingbar, kann man sie nachträglich noch hinterlegen - das ist immer noch deutlich einfacher, als sich das ganze Gedöhns von Anfang an aufzubürden.

    Aber Einsteiger sollten als allererstes ihr VisualStudio so einstellen, dass sie Datentypen überhaupt unterscheiden lernen - das ist leider keine Selbstverständlichkeit
    Visual Studio - Empfohlene Einstellungen

    Danach(!!!) lohnt sich vielleicht ein Blick in die vier Views-Videos, um eine Vorstellung von den Konzepten der .Net-Datenverarbeitung zu kriegen.
    Es wirklich lernen ist mühsam, ich glaub immer noch, dass man sich anhand der in Datenverarbeitungs-Vorraussetzungen gegebenen Tutorial-Sammlung am schnellsten weiterentwickelt.
    (Jepp - als Einsteiger ist nämlich das wichtigste, sich selbst zu entwickeln - die Anwendung ist dagegen Nebensache)

    Hi und danke für die Rückmeldung.

    Opiton Strict war mir bisher kein Begriff - werde ich mir aber definitiv näher anschauen, mit Option Explicit hatte ich bereits in Excel VBA gearbeitet und das auch immer auf "ON" gelassen.
    Das mit dem Schreiben in z.B. xml-Dateien ist eine teilweise gute Sache, ich würde aber die Datenbank-Methode bevorzugen wollen.

    Deshalb auch meine Frage, ob das über meinen gedachten Weg überhaupt lösbar ist. Ich möchte hier keinen fertigen Code präsentiert bekommen, denn
    ich möchte Schritt für Schritt dazu lernen - einen Lösungsansatz mit welcher Methode das machbar wäre würde mir genügen. Mein Projekt ist nichts, was eilig ist oder produktiv eingesetzt werden soll - das übernimmt aktuell die Excel-VBA-Variante
    und die benutze nur ich, um mir ein paar Arbeitsschritte zu vereinfachen. Es hat sich dort jedoch herauskristallisiert, dass das inzwischen weniger mit Excel, sonder mehr
    mit Datenbank zu tun hat (Excel-Tabellen sind dort aktuell meine "Datenbank" :) )

    Ich kann das Ganze auch über Textboxen und "feste" SQL-Strings lösen - das ist gar keine Frage, jedoch fände ich persönlich meinen in Frage gestellten
    Weg sinnvoller, gerade wenn es sich um Datenbanken mit unterschiedlichen Inhalten und Spaltenanzahlen handelt.

    LG
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Das mit der Datenbank überdenke nochmal.
    Aber wenn du drauf bestehst hab ichs ja verlinkt - als den zweit-einfachsten Weg.
    Nützt dir aber nichts, den einfachsten Weg musst du trotzdem lernen - ohne jeden Abstrich.
    Also der zweit-einfachste ist quasi der einfachste Weg (und der ist schon schwierig genug) plus Datenbank-Connectivität dazu (nochmal schwierig, anfällig und v.a. unflexibel).
    Aber wie wolle.

    Nicht wie wolle ist die Sache mit Strict On. (was übrigens was ganz anneres ist als Explicit)
    Und wie gesagt, das ist Grundvorraussetzung, dass du .Net-Programmieren überhaupt richtig erlernen kannst. Und es geht da nicht nur um Strict On, sondern auch um den "Deppen-Namespace" Microsoft.VisualBasic, welcher unbedingt aus den GeneralImporten zu entfernen ist.
    Also Visual Studio - Empfohlene Einstellungen ist Must-Do-Immediately-No-Excuses!
    Ist blöd, weil worums da geht, kannste inhaltlich erst richtig verstehen, wennde einigermassen Grundlagen gelernt hast.
    Trotzdem ist das am besten von Anfang an umzusetzen, weil sonst gewöhnst du dir einen schlechten Stil an, und gewöhnst dich an wirklich dumme Vorgehensweisen, umständlich und fehleranfällig - und diese Gewohnheiten werden die Leuts über Jahre nicht los, weil funktioniert ja (so recht und schlecht).
    Wie's aber richtig funktionieren könnte - das bleibt ihnen verschlossen, da stehen sie sich dann regelmässig selbst im Weg mit ihrem "funktionierenden" Krepel-Code.
    Grade wo du von VBA her kommst bist du anfällig dafür, weil du hast die ganzen VB6-Gewohnheiten, die in VBA richtig waren.
    VB.Net ist aber anders, und ist um Welten besser, aber deine VB6-Gewohnheiten sind hier Krepel.


    Übrigens dein gedachter Weg ist so nicht vorgesehen und auch nicht sinnvoll. Was vorgesehen ist, ist um Welten besser - aber musste halt lernen.
    Eine .Net-Datenbank-Anwendung verkapselt die automatisch generierten Sql-Anweisungen so, dass du als Programmierer normal nie damit zu tun hast.
    Erst wenns richtig fett wird, so ab 100000 Datensätze, dann musste dir die DataAdapter mal vornehmen und mengen-reduzierendes Sql dranbasteln.


    Aber vlt. verstehe ich dich auch ganz falsch. Du redest von Datenbanken - wieso benötigt deine Anwendung mehrere davon?
    Üblicher- und sinnvoller-weise kennt eine Anwendung genau eine Datenbank, wo aber auch wirklich alles drinne ist.

    Ein Datenbank-Tool ist wieder was anneres, aber da frage ich mich: Was ist am Access-FrontEnd falsch, dass du ein eigenes Datenbank-Tool brauchst?

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

    Wie schon gesagt, ich werde mich mit den Grundeinstellungen etc. wie empfohlen auch auseinandersetzen.
    Mir ist es schon wichtig, dass es direkt "richtig" programmiert wird.

    Mehrere Datenbanken möchte ich nutzen, um die Inhalte der einzelnen Programmteile zu trennen und sollte sich mal eine DB
    "zerschießen" bleiben die restlichen Daten immerhin noch da (und ja, eine Backupfunktion wird natürlich mit eingebaut :) ). Mein Tool ist dazu gedacht, Datenbanken zu erstellen - editieren - löschen.
    Ich habe mal ein Bild meiner UserForm angefügt.

    Erst wenn der Programmteil "steht" und funktioniert, kommt der Rest - denn darauf wird der Großteil aufbauen.
    Ob das nun Sinn macht oder nicht - ich sehe das als Herausforderung und möchte das gerne so umsetzen :)

    Danke für die Tipps bisher.

    LG
    Bilder

    • unbenannt.png

      86,96 kB, 1.606×898, 80 mal angesehen
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

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

    Hmm.
    Also Tabellen anlegen, Spalten, Datentypen - dafür ist doch das Access-FrontEnd da.
    Und Nullable/NotNullable, Primärschlüssel, Fremdschlüssel, Relationen - willst du das auch alles selber programmieren in deim Datenbank-Verwaltungs-Tool?
    Weisst du überhaupt, was eine Relation ist, und inwiefern Relationen das wesentliche sind an einer relationalen Datenbank?

    Hihi - Solch Unterfangen nennt man wohl mit Fug und Recht: "das Rad neu erfinden" ;)
    google mal den Ausdruck - er ist durchaus nicht un-tiefsinnig.

    Access als Frontend wollte ich mir sparen / bzw. nur für den Fall der Fälle nutzen, falls ich mal händisch an die Daten dran müsste.
    Die spätere Anwendung wird u.a. auch auf PC's laufen sollen, die kein Access installiert haben.

    Ich habe mal ein "Datenbankdesign" angehangen, wie ich es mir vorstelle - so in etwa würde das aussehen. Ich würde das dann doch
    in eine Datenbank zusammenpacken, ich hatte erst eine andere Denkensweise. Denn für viele der Tabellen gibt es aktuell für jedes Jahr eine Excel-Datei
    Somit hätte ich dann z.B. die Datenbank "Urlaubsplaner" erstellt mit den entsprechenden Tabellen für die Jahre - aber
    die Datenbank kann so ein paar Jahre denk ich "locker" wegstecken. (365 Zeilen pro Jahr :) )

    Von nun an soll die Anwendung folgendes erfüllen:
    - Lesen bestimmter Daten aus den Tabellen der Datenbank -> mit entsprechender Darstellung in Tabellen/Boxen/Labels etc.
    - bearbeiten/verändern dieser Daten aus den Boxen / Tabellen heraus
    - hinzufügen neuer Datensätze über entspr. Boxen
    - ein paar Funktionen ausführen die vermutlich über Excel laufen (Tabellen formatieren, füllen und über Outlook verschicken)

    - über ein "Verwaltungstool" wäre es nice-to-have Funktionen einzusezten wie z.B.
    Für ein neues Jahr:
    "fülle mir Tabelle "xy" mit Datum vom 01.01.JAHR bis einschl. 31.12.JAHR -> dazu die entsprechenden Wochentage (mit Angabe von Feiertag, wenn dann einer ist) und Kalenderwochen"
    "fülle mir Tabelle(n) "x", "y", "z" mit Namen der Mitarbeiter aus Tabelle "Stammdaten Mitarbeiter"
    "auswertung der beziehungen: an Datum "xy" hat Mitarbeiter "xy" Urlaub gehabt, ist Tour gefahren usw." -> nach meinem Verständnis ist ja genau das der Sinn und Zweck von Beziehnungen.

    -> liese sich vermutlich über eine For ... Next-Schleife machen.

    usw.

    Wäre das nun realistischer als mein erster Ansatz? :)

    Und so, wie ich es verstanden habe soll das ganze Datenmodell über Visual Studio und nicht über Code verwaltet werden? Es wäre mir aber wichtig, dass die
    Datenbankdatei separat behandelt und nicht in das Projekt eingebunden wird. Ich hätte sonst das "Problem" dass bei einem Update der Anwendung die aktuellen Live-Daten
    mit denen aus meiner Projektversion überschrieben würden. Dazu frage ich beim Öffnen der Anwendung das Datenverzeichnis samt Datenbankdatei ab (welches später ggf.
    auf einem Netzlaufwerk liegen wird) - findet die Anwendung die Datei nicht, wird zur Auswahl angehalten - erst dann geht es weiter. Somit ist gewährleistet dass die Anwendung nur
    läuft wenn die Datenbank vorhanden ist. Was ich noch nicht verstanden habe ist die "automatische Verwaltung / Funktion der SQL-Abfragen" - aber hier werde ich mich weiter einlesen,
    Links hatten Sie mir ja genügend zur Verfügung gestellt.

    LG
    Bilder

    • Unbenannt.PNG

      392,77 kB, 1.462×983, 84 mal angesehen
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „tragl“ ()

    tragl schrieb:

    Wäre das nun realistischer als mein erster Ansatz?
    Jo, dassis nachvollziehbar, und auf sowas hin ist die .Net-Datenverarbeitungs-Infrastruktur auch ausgerichtet.
    VisualStudio braucht die DB-Datei nicht ins Projekt eingebunden haben, es reicht der ConnectionString in den Settings.
    Allerdings ist das fürs erste irrelevant, dieses Jahr wirst du noch mit anderem zu tun haben, als der Frage, auf welches Netzlaufwerk, und welcher ConnectionString.
    Das einfachste ist (nein, das zweit-einfachste), du fügst die .accdb dem Projekt hinzu, generierst dir dein typisiertes Dataset, und schliesst die .accdb per KontextMenü wieder aus.
    Dann hast du einen funktionierenden Connectionstring in den Settings - den kannste da auch anpassen.
    Aber wie gesagt: Irrelevant. Das kannste in einem Jahr genausogut machen wie heute.
    (Nur dass du dich in einem Jahr insgesamt besser auskennst)


    Was ist das für ein ER-Diagramm - welches Tool?
    Die PfeilSpitze bezeichnet den PrimaryKey einer Relation, oder?

    Hi,

    durch das Entfernen der Deppeneinstellungen habe ich am heutigen Tag schon einiges dazu gelernt und habe das Projekt komplett neu aufgesetzt.
    Die (jetzt nur noch eine) Datenbank habe ich über ein Rich-Text-Feld komplett Strukturiert (wie es im Designer zu sehen war), darüber kann ich mir
    die Datenbank / Tabellen / Daten auch ggf. ändern usw.

    Was mich wundert ist, dass ich trotz des Entfernens des Verweises Microsoft.VisualBasic dennoch kein ctype benutzen MUSS, intellisense
    meckert dennoch wenn 2 datentypen nicht zusammenpassen, das sollte auch reichen :)

    Die kommenden Tage schaue ich mir dann die Sache mit dem Reinziehen der accdb-Datei und anschließendem Entfernen via Kontextmenu an,
    der Rest ergibt sich dann hoffentlich von selbst. Vielen Dank nochmal für die guten Tipps! :)

    LG
    Bilder

    • unbenannt.png

      86,96 kB, 991×1.192, 71 mal angesehen
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    tragl schrieb:

    Was mich wundert ist, dass ich trotz des Entfernens des Verweises Microsoft.VisualBasic dennoch kein ctype benutzen MUSS
    Da bringste 2 Sachen durcheinander.
    Der Deppen-Namespace - dassis der GeneralImport auf Microsoft.VisualBasic - der hat nix mit CType zu tun, sondern wenn der ausgeknipst ist, spielt dir Intellisense nicht ununterbrochen den ollen vb6-Crap unter die Finger.
    CType hat mit Option Strict On zu tun.
    CType() heist lang ausgesprochen "convert type", und Typen konvertieren kommt eh nur in Frage, wenn sie nicht zusammenpassen.
    Und das ist ein schlechtes Zeichen, denn wenn man mit Bedacht programmiert, wählt man seine Datentypen so, dass sie zusammenpassen.
    Die ganze Sprache - alle Datentypen! - wurde so entworfen, dass sinnvolles zusammenpasst, und unsinniges nicht.
    Ausnahmen sind möglich - dafür gibts CType(). Aber die Regel ist, dass Dinge zusammenpassen, und CType dann natürlich nicht erforderlich ist.

    Wie dem auch sei: Wenn bei unpassenden Datentypen nur Intellisense meckert, du aber trotzdem kompilieren kannst, dann haste Strict On noch nicht angeschaltet.
    Unsinn darf nur kompilieren, wenn du es (mittels CType()) erzwingst.
    Also nochmal: Visual Studio - Empfohlene Einstellungen - richtig machen - da gibts kein Pardon!

    Option Strict steht auf on. Wenn intellisense meckert dann suche ich einen Weg, dass die beiden Typen zusammenpassen (muss dann einer geändert werden), anstelle
    ctype zu benutzen. Ich denke so soll's auch sein :)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Gibt es btw. eine Simple Lösung, um die Beziehungen innerhalb der Datenbank zu testen?
    Beispiel:

    Tabelle Stammdaten Mitarbeiter
    Spalte Mitarbeiter = PrimaryKey

    Tabelle Urlaub
    Spalte Mitarbeiter = PrimaryKey

    wenn ich die beiden 1:1 verknüpfe, kann ich in Access dennoch in der Tabelle "Urlaub" bei Mitarbeiter eingeben, was ich will - da wird nix
    überprüft. Gibt es hier eine einfach Methode um die Beziehungen durchzutesten?

    LG

    PS: Wenn das hier an der falschen Stelle ist, poste ich das gerne nochmal woanders.

    EDIT: hat sich erledigt
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

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

Facebook
Telefonspende