Anzahl der Spalten im table zählen

  • VB.NET

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

    Anzahl der Spalten im table zählen

    Bestimmt gibt es dazu schon irgendwo info's hier im Forum.

    Ich möchte aus einer Unbekanten datenbank die Namen der Tables auslesen.
    Dann die Anzahl der Spalten in den Tables.

    Um dann einem dgv die columns zu adden.

    Das kann doch nicht so schwer sein, aber irgendwie habe Ich noch nichts brauchbares gefunden.
    "Mann" lernt mit seinen Projekten.

    Das geht schon, nur braucht man sowas eiglich nie.

    Wenn man ein Proggi schreibt, was auf eine DB zugreift, dann sollte man die gegebenen Tabellen und Spalten bereits kennen - andernfalls kannman ja nix vernünftiges dafür programmieren.

    Ist das die DB mit der Tabelle mit den über 200 Spalten, die aber ganz sicher kein Datenmodell-Fehler ist ;)?

    egal - gugge Datenbank-Schema auslesen

    Genau, das ist die Datenbank.

    was Ich dort vorhabe ist halt so nen tool, mit dem Ich die DB einlesen kann und nach bestimmten regeln Werte ändere.
    zb. wenn wert1 = x dann wert2 = y

    Wir arbeiten bei uns im Unternehmen momentan mit einer mischung aus Access und Excel soll heißen Ich kopiere daten aus Access in excel, ändere die dort und füge sie wieder ein.

    Ich möchte mir nun das Leben vereinfachen. :thumbup:
    Hinzu kommt, das wir gerade mal eine Hand voll leute hier sind, die überhaupt mit Access annähernd umgehen können um diese Spielchen zu betreiben.
    Die wahrscheinlichkeit, das Die die komplette DB löschen ist sehr hoch :wacko:

    Die Datenbanken sind prinzipiell gleich, aber bei der einen sind ev. 2-3 andere Spalten drinn als in der anderen.
    Und somit laufe Ich halt wieder in fehler des readers rein.

    Wenn Ich nun eine maximalauslegung des dgv machen könnte und bei nicht vorhandenzein der Spalte in der DB diese übersprungen wird, währe das auch eine Möglichkeit.

    Momentan rufe Ich in eine Schleife die Spalten des dgv ab und verwende den Namen um die Daten aus der DB zu lesen.
    Ev. umständlich, aber erstmal funktioniert es und Ich binn ja nunmal auch ncoh Anfänger.

    Ev. gibt es ja einen einfachen Lösungsweg, den Ich erst einmal gehen könnte um micht nicht als zu tief mit sql zu befassen.
    Ich möchte ersteinmal ein ergebniss haben mit dem Ich arbeiten kann. Und dann baue Ich access nach. ;)
    "Mann" lernt mit seinen Projekten.

    KSE schrieb:


    Also meiner Meinung nach ist das kompletter Unfug. Du solltest eher eine sinnvolle und dauerhafte Lösung schaffen oder schaffen lassen...
    Diese Meinung kann Ich nicht so direkt untestützen.
    Denn Ich lerne das Programmieren nicht für die Firma, sondern weil Ich das schon immer mal machen wollte.

    Und Ich finde es von großem vorteil das Ich das frish gelernte in kleine Projekte direkt mit einbringen kann, welche mir die Arbeit erleichtern.

    Ich wüßte jetzt so auf anhieb nicht so direkt was ich für Mich so privat programmieren sollte.

    Ich finde es einfach klasse die Arbeitsweise und Gedankengänge welche sich über Jahre entwickelt haben, jetzt mit den neuen Möglichkeiten in Programme umzusetzen.
    "Mann" lernt mit seinen Projekten.

    kiter20 schrieb:

    Die Datenbanken sind prinzipiell gleich, aber bei der einen sind ev. 2-3 andere Spalten drinn als in der anderen.
    Und somit laufe Ich halt wieder in fehler des readers rein.


    Darf man fragen warum das so ist? Warum gibt es Datenbanken bei euch die 2-3 Spalten mehr haben als andere? Sind ansonsten die Spalten (vor allem deren Datentypen) identisch?
    Von wie vielen verschiedenen Datenbanken reden wir hier?

    Vielleicht wäre der billigste "Workaround" ja die fehlenden 2-3 Spalten(mit Dummy oder 0-Werten) einfach an die Tabellen in den betreffenden Datenbanken anzuhängen?

    Natürlich darf man, und Ich werde es auch versuchen zu erklären.

    Es handelt sich dabei, wie schon erwähnt, um eine DB für unsere Maschinen.
    Die Anlagen laufen Windows basierend nun seid ca. 8 Jahren und seid dem sind immer wieder Parameter in der DB hinzugekommen, weil die Anlagen auch immer komplexer werden.
    Somit ist es schwierig dort einfach Spalten hinzuzufügen. Es kommt auch noch hinzu, dass, wenn ich einfach dort Spalten hinzufügen, die Maschinenoberfläche auch anfangen würde diese zu verarbeiten. und das möchte ich ja nun nicht.
    Wenn dort Parameter hinzu gefügt werden, geschied dies in enger Absprache mit den Programmierern.

    Ich hatte halt gedacht, das Ich irgendwie ganz einfach an die anzahl der Spalten ran komme und dann zb über eine Schleife und die IDNummer dann den Table komplett auslese.

    Mir scheint es aber so, das Ich nicht da drum herum kommen werde micht früher als mir lieb ist micht damit auseinander zu setzen.

    Learning by doing.
    "Mann" lernt mit seinen Projekten.

    Prinzipiell funktioniert das schon fast so wie Ich das möchte.

    Aber der Versuch den RowAdd in Zeile 33 auch dynamisch zu gestalten ist fehlgeschlagen.
    Es wird in Spalte(0) der generierte Inhalt von stringRowAdd aus Zeile 28 angezeigt.

    Wie kann man das lösen ?

    VB.NET-Quellcode

    1. 'Profildaten lesen
    2. Dim con As New OleDbConnection
    3. Dim cmd As New OleDbCommand
    4. Dim reader As OleDbDataReader
    6. con.ConnectionString =
    7. "Provider=Microsoft.Jet.OLEDB.4.0;" &
    8. "Data Source=" & (Path.Combine(PfadDatenbank, "Profildatenbank.mdb"))
    9. cmd.Connection = con
    10. cmd.CommandText = "select * from Profilliste"
    12. Try
    13. con.Open()
    14. reader = cmd.ExecuteReader()
    16. 'Columns schreiben
    17. For i = 0 To reader.FieldCount - 1
    18. form1.dgvProfilListe.Columns.Add((reader.GetName(i)), (reader.GetName(i)))
    19. 'Auswahlfelder füllen
    20. form1.lstWert1.Items.Add(reader.GetName(i))
    21. form1.lstWert2.Items.Add(reader.GetName(i))
    22. Next
    24. 'String für den RowAdd erstellen
    25. Dim stringRowAdd As String
    27. For i1 = 0 To reader.FieldCount - 1
    28. stringRowAdd &= "reader(" & i1 & "), "
    29. Next
    31. Do While reader.Read()
    33. form1.dgvProfilListe.Rows.Add(stringRowAdd)
    35. Loop
    36. reader.Close()
    37. con.Close()
    39. Catch ex As Exception
    40. MessageBox.Show(ex.Message)
    41. End Try


    "Mann" lernt mit seinen Projekten.

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

    So, das DGV wird befüllt.
    Aber dafür gibt es doch bestimmt auch einen besseren Weg :whistling:


    VB.NET-Quellcode

    1. 'dgv befüllen
    2. Dim ActualRow As Integer = 0
    3. Do While reader.Read()
    6. form1.dgvProfilListe.Rows.Add(reader(0))
    8. For i1 = 1 To reader.FieldCount - 1
    9. form1.dgvProfilListe.Rows(ActualRow).Cells(i1).Value = reader(i1)
    10. Next
    12. ActualRow += 1
    15. Loop
    16. reader.Close()
    17. con.Close()
    "Mann" lernt mit seinen Projekten.

    Entschuldigung, ich muss jetzt einfach mal zwischenfragen: Wo liegt das Problem?

    Als blutiger Anfänger möchte ich hier nicht zwischen Mühlsteine geraten - aber ist es nicht so, dass ich eine x-beliebige Datenbank in ein DataTable laden kann, dieses an ein DGV binde und alles vollautomatisch korrekt dargestellt wird?
    Und bei Verwendung eines CommandBuilders kann ich sogar Änderungen ohne Programmier-Aufwand zurückschreiben - auch mehr oder weniger vollautomatisch? :?:
    Das Leben ist nicht so kompliziert. Eine süsse Erinnerung tut's.
    Indiana Jocutus - Jäger des Variablen-Schatzes

    Du kannst nicht eine Datenbank in eine DataTable laden, sondern nur eine (von vielen) DB-Tabellen.
    Das Problem ist, son generisches Proggi kennt nicht die Bedeutung der Daten.

    Hier etwa will der User vlt. eine Maschine auswählen, und dann einen Arbeitsgang, der vlt. aus 15 Arbeitsschritten besteht, und will Schritt 3 löschen, 2 neue Schritte zufügen, und dann die Maschine damit ansteuern.
    Sowas "sinnvolles" kannst du nur proggen, wenn das Datenmodell entsprechend konzipiert und dem Proggi bekannt ist.

    Also generisch kann man vlt. einen RohDaten-Browser proggen, mit dem man alles angugge (und kaputtmachen ;)) kann, aber keine Nutzanwendung.
    guggemol DataViewer

    Natürlich - keine Datenbank sondern die Tabelle in DataTable laden. Da war ich zu schnell beim Denken.

    Aber um nochmal auf das eigentliche Problem zurückzukommen: Wäre ".Getschema(schemaName)" nicht genau das Richtige? Alle Tabellen in der Datenbank werden aufgelistet, alle Felder in einer Tabelle können aufgelistet werden - inklusive der dazugehörigen DatenTypen. Damit wäre doch alles zur Hand, was man für die sichere Nutzung braucht...
    Das Leben ist nicht so kompliziert. Eine süsse Erinnerung tut's.
    Indiana Jocutus - Jäger des Variablen-Schatzes

    Habich mit Datenbank-Schema auslesen ja empfohlen, inklusive Beispiel.

    Aber "genau das richtige" wäre imo, das ganze System von Grund auf neu und richtig aufzusetzen.
    Grad weil @Kiter20: keine Erfahrungen mit der Materie hat, ists besonders ungünstig, denn beim Weiterwursteln im vorliegenden Chaos-System kann er garkeine nützlichen Erfahrungen machen, sondern nur schädliche.

    ErfinderDesRades schrieb:

    Aber "genau das richtige" wäre imo, das ganze System von Grund auf neu und richtig aufzusetzen.

    Welches System ?

    Das DB System kann Ich nicht ändern.

    Also zum jetzigen Zeitpunkt muss Ich sagen, dass Ich mit meinem Ergebniss ganz zufrieden binn.

    Ich kann einen bestimmten Table einlesen (Inhalt unbekannt)
    Adde die Spalten zum dgv
    kann im DGV inhalte ändern, diese werden direkt in die DB geschrieben.

    Ich kann einen Wert aus einer beliebigen Spalte abfrage und vergleichen und somit die row festlegen, in der
    der wert einer bestimmten Spalte in einen anderen geändert wird.

    Mag vlt. sein das mein Stil nicht ganz sauber ist, aber das wird vielleicht noch.
    Ich binn es gewohnt mit Variablen zu arbeiten, dar die NC Programme auf unseren Anlagen welche Ich schreibe variabel Programmiert sind.
    "Mann" lernt mit seinen Projekten.

    kiter20 schrieb:

    Welches System ?
    Na, alles. Wenn ich recht verstehe, verwendet ihr da mindestens mehrere .mdb-Dateien, mehrere Excel-Worksheets, und eine vb.Net-Anwendung, um eure Arbeitsergebnisse zu erzielen.

    Ist sicherlich erfreulich, dasses tut, wasses soll, aber denk blos nicht, du hättest hier jetzt einen "Learning by Doing"-Erfolg.
    Denn du hast nur eine Erfahrung gesammelt, wie man es möglichst nicht machen sollte. Also was nützliches hast du dabei nicht gelernt, sondern höchstwahrscheinlich eine schlechte Angewohnheit, die du beim nächsten Problem vmtl. wieder reproduzierst.
    Diese Angewohnheit steht dir nun im Weg, wenns drum ginge, Datenbänkerei nach Stand der Technik zu erlernen. Weil nach Stand der Technik braucht man weder Excel-InterOp noch DataReader.

Facebook
Telefonspende