[VB.net] - Select Befehl mit Datenbindung

[Kurz (Gast)]

Hallo Leute,

Will bei einem kleinen .net Programm eine DataTable in ein Datagridview 
laden und danach mit einer Select anweisung filtern.

(Laden und hinzufügen eines Eintrags, klappt ja schon)

Leider klappt das filtern nicht so ganz.

Hat jemand eine Idee?

[Kurz (Gast)]

Oder mache ich generell was falsch?

[Irgend W. (Firma: egal) (irgendwer)]

Kurz schrieb:
> Oder mache ich generell was falsch?
So wie es aussieht legst du zwar eine SQL-Abfrage fast, führst diese 
aber garnicht aus. Bzw. du fragst erst die Daten ohne definierten select 
ab und legst dann erst den select fest.

Zitat: "Ein SqlCommand, mit dem während der Ausführung von Fill(DataSet) 
in der Datenbank Datensätze ausgewählt werden, die in das DataSet 
eingefügt werden sollen."
- 
https://docs.microsoft.com/de-de/dotnet/api/system.data.sqlclient.sqldataadapter.selectcommand?view=dotnet-plat-ext-6.0

[Schlaumaier (Gast)]

Unter VB geht das so.

dim sql as string


sql = "Select * from Datenbank where feld_name = '" + hp_e_name.text + 
"'"

Dim cmd As New OleDbCommand(sql, conn)
    Dim da As New OleDbDataAdapter(cmd)
    Dim ds As New DataSet
    Dim commandBuilder As New OleDbCommandBuilder(da)
    conn.Open()
    ds.Clear()
    da.Fill(ds, tabelle$)
    '  Dim row As DataRow
    Dim dt As DataTable = ds.Tables(tabelle$)
    gg_db_suche.AutoGenerateColumns = False
    gg_db_suche.DataSource = dt
    conn.Close()


ABER nicht vergessen.

Im Datagridview die Datenfelder Anmelden. Also bei  DatapropityName den 
Namen der Spalte eintragen, damit das Feld richtig zugeordnet wird.

[Schlaumaier (Gast)]

Nachtrag: OleDbCommand ist für Access-Datenbanken.

Für SQLite Datenbanken sieht das SO aus.

Dim sql_cmd As New SQLiteCommand(my_sql, sql_conn)
    Dim sql_da As New SQLiteDataAdapter(sql_cmd)
    Dim sql_ds As New DataSet
    Dim sql_commandBuilder As New SQLiteCommandBuilder(sql_da)


Ist fast genau das selbe. Bloss das du ein anderen Datenadapter setzt.


Den setzt man global. z.b. für SQLite

Private sql_dbpath As String = 
System.IO.Path.Combine(Application.StartupPath, "Datenbank.db")

Private sql_conn As New SQLiteConnection("Data Source=" & sql_dbpath & 
";")



Kleiner Tipp.

Setzt ich Datagridview IMMER in Spalte 0 die ID des Datensatzes. 1 kann 
man dann einfacher zählen für das Füllen von Hand. und 2. kannst du dann 
ohne Änderungen IMMER den Datensatz identifizieren. Was interessant ist, 
wenn das Datagridview nur ein kleinen Teil des Datensatz anzeigt.

z.b. Name + Vorname

Und du durch anklicken der Zeile den Rest unten anzeigt.

[leo (Gast)]

Schlaumaier schrieb:
> sql = "Select * from Datenbank where feld_name = '" + hp_e_name.text +
> "'"

und fertig ist die SQL-Injection. Bitte hör einfach auf, deine 
"Schlau"heiten zu verbreiten.

leo

[Schlaumaier (Gast)]

leo schrieb:
> und fertig ist die SQL-Injection. Bitte hör einfach auf, deine
> "Schlau"heiten zu verbreiten.

Ja für Leute die nicht in der Lage sind, Eingabefelder auf Gültigkeit zu 
prüfen. Meine Eingabefelder kannst du nicht einmal verlassen, ohne eine 
Gültigkeitsprüfung.

Diese relativ langen Code ist bei mir eine Funktion die den Feld-Wert 
übergeben bekomme, und ein True o. False zurück liefert.

Aber Leute wie ihr seit es ja nicht mehr gewohnt, Eingaben auf 
Gültigkeit zu prüfen. Deshalb passieren ja so Spielchen.

Irgendwoher muss ja die Abfrage wissen, was sie abfragen soll.

[Jemand (Gast)]

Schlaumaier schrieb:
> Aber Leute wie ihr seit es ja nicht mehr gewohnt, Eingaben auf
> Gültigkeit zu prüfen. Deshalb passieren ja so Spielchen.

Nein, die passieren wegen Spinnern, die SQL Abfragen als Strings 
zusammenbauen statt die Parameter-API zu nutzen.

Schlaumaier schrieb:
> Irgendwoher muss ja die Abfrage wissen, was sie abfragen soll.

RTFM

[c-hater (Gast)]

Schlaumaier schrieb:

> Nachtrag: OleDbCommand ist für Access-Datenbanken.

Ähem, nö. Die OleDB-Ausprägung der diversen .net Datenklassen kann man 
natürlich mit JEDER Datenbank benutzen, für die es einen 
OleDb-Provider gibt. Aber natürlich nur dann, wenn der gewünschte auch 
installiert ist.

Dasselbe gilt auch für die ODBC-Geschichte. Nur hat Microsoft für ODBC 
ein recht schickes GUI gebaut, wo man u.A. problemlos nachschauen kann, 
welche Treiber installiert sind und wie die genau heißen, dies aber aus 
unerfindlichen Gründen für OleDb unterlassen.

Um das für OleDB herauszubekommen, muss man leider in die Untiefen der 
Registry herabsteigen. Wenn man den Umgang mit der Registry gewohnt ist, 
ist das kein großes Problem. Das Problem ist der Rest des 
Connection-Strings. Dann das steht nicht in der Registry und ist bei 
jedem OleDB-Provider (wie auch bei den ODBC-Treibern) immer ein wenig 
verschieden.

Interessanterweise haben alle "großen" Datenbanken sowohl ODBC-Treiber 
als auch OleDB-Provider (meist sogar in einem einzigen gemeinsamen 
Installationspaket) anzubieten. Die Dinger sind allerdings mehr oder 
weniger schwer zu finden und überdies typisch recht lausig dokumentiert. 
Zumindest ist die Doku meist noch schwerer zu finden als die 
Treiberpakete.

Aber, wenn man erstmal weiß, dass es das alles durchaus gibt, dann 
findet man den Kram auch. Durch geduldiges und kompetentes Suchen...

[Schlaumaier (Gast)]

c-hater schrieb:
> Aber, wenn man erstmal weiß, dass es das alles durchaus gibt, dann
> findet man den Kram auch. Durch geduldiges und kompetentes Suchen...

OHJA.

Aber ich meinte mit Access das ICH so auf meine Access-DB Zugreife. Die 
ich aber nicht für ernste Datenbankanwendung nutze.

Und dafür brauche ich KEINE extra Libs/DLL einbinden. Da reicht ein 
einfacher Befehl.

Für SQLite muss ich 3-4 DLL einbinden.

Und über ODBC komme ich an fast jede Datenbank ran. Ich musste damals 
mit VB-6.0 mit einer AS-400 so verbinden. Ich musste zwar über 400 MB an 
Treiber und Co. installieren aber es hat danach super geklappt.

Das Programm lief in mehrere Versionen über 7 Jahre. Da wurde wir an die 
Mutterfirma angeschlossen.