OledB Datareader HasRows permanent false

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von fabimaurice.

    OledB Datareader HasRows permanent false

    Hi,

    habe ein Problem mit dem Datareader unzwar ist mein Ergebnis immer HasRows = False auch wenn Theoretisch Ergebnisse der Abfrage bereitstehen.
    Das Statement habe ich getestet per Abfrageassistent da funktioniert alles. Parameter stimmen auch alle jedoch findet er trotzdem kein Ergebnis...
    Solange HasRows jedoch auf false steht wird leider auch kein Code innerhalb der while Schleife ausgeführt.



    Sofid ist eine SelectedValue aus einer Combobox und PcId wird per Hauptform an diese übergeben und ist auch bloß ein Autoinkrementaler Wert der wie gesagt stimmt.
    Mein Code:

    VB.NET-Quellcode

    1. Dim con As New OleDbConnection
    2. Dim cmd As New OleDbCommand
    3. Dim reader As OleDbDataReader
    4. con.ConnectionString = Conn
    5. cmd.Connection = con
    6. Dim obj = CType(CboSoftware.SelectedItem, ClsSoftware)
    7. cmd.CommandText = "SELECT id, license, overall FROM Licenses WHERE id NOT IN (SELECT Li_ID FROM LicensePc WHERE Co_ID = @pcid) AND software_id = @sofid"
    8. cmd.Parameters.AddWithValue("@sofid", obj.id)
    9. cmd.Parameters.AddWithValue("@pcid", PcId)
    10. con.Open()
    11. reader = cmd.ExecuteReader
    12. While reader.Read
    13. licenselist.Add(New clsLicenses(reader("id"),
    14. reader("license"),
    15. reader("overall")))
    16. End While
    17. reader.Close()
    18. con.Close()


    Wenn jemandem etwas ein oder auffällt bin ich unglaublich dankbar :) .


    Mit freundlichen Grüßen
    Fabimaurice

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

    Kleine Nachträge.

    Es liegt am Sql Statement und dort wahrscheinlich an dem Parameter @pcid. Wenn ich diesen explizit angebe Funktioniert es wenn ich jedoch den parameter selbst im Statement hinter der "Not In" Abfrage benutze funktioniert es nicht. Warum verstehe ich bisher nicht alle zusammenhängenden Variablen oder Tabellenspalten habe ich überprüft und bei allen ist der richtige Datentyp angegeben.

    ErfinderDesRades schrieb:

    welchen datentyp gibst du denn an? Und welchen Datentyp hat PcId?

    Beides Integer.

    "akt" Code? meinst du den aktuellen Code oder ist damit etwas bestimmtes beschrieben?

    Edit:
    @ErfinderDesRades
    Wenn ich den Command ohne

    VB.NET-Quellcode

    1. AND software_id = @sofid
    nutze funktionierts ????

    VB.NET-Quellcode

    1. "SELECT id, license, overall FROM Licenses WHERE id NOT IN (SELECT Li_ID FROM LicensePc WHERE Co_ID = @pcid) " 'AND software_id = @sofid

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

    Hi,

    Schade das wohl niemand etwas wusste oder einfach niemand lust hatte zu antworten immerhin hat EDR versucht zu helfen. Das Problem habe ich gerade eben recht schnell sogar gelöst bekommen nach langen überlegen jedoch. Es liegt daran das die Parameter wohl so abgerufen werden das der Erste im SQL Statement erwähnte Parameter nicht nach Parameternamen auswählt sondern sich einfach den Parameter nimmt der als erstes hinzugefügt wird. Quasi wird immer diesselbe Position genutzt der 2te den 2ten etc.
    Also hat er hier einfach die falsche id dafür genutzt eher gesagt eine nicht existierende.

    mfg
    fabimaurice
    hmm - OleDbCommand.
    OleDbCommand klingt mir nach Access, und da kenne ichs so, dass Parameter-Platzhalter im Sql-Statement einfach ein namenloses ? ist, und das geht der Reihenfolge nach.
    Probier mal aus, obs statt benannter Params auch mit ? geht.
    Dann ist die ?-Syntax wohl nicht Access-spezifisch (wie ich bislang dachte), sondern OleDb-spezifisch.
    Aber nur Vermutung.
    Und wundern täte mich dann, dasses zusätzlich auch mit benannten Params gehen sollte, sich dann aber definitiv falsch verhält.

    ErfinderDesRades schrieb:

    Probier mal aus, obs statt benannter Params auch mit ? geht

    Ja das klappt, das ganze ist aber meiner Meinung nach tatsächlich falsches Verhalten von OledB. Aber weil ich daran jetzt solange gesucht hatte dachte ich mir das ich einfach mal SQL ausprobiere statt OledB und bin daher auf Sqlite umgestiegen was meiner Meinung nach übrigens auch sehr viel Performatner läuft^^.
    Hab da jetzt noch ein Zwei Probleme gehabt mit dem löschen von Referenzeinträgen da das bei OledB wohl automatisch konfiguriert ist bei SQL musste ich dafür dann einfach "ON DELETE CASCADE" in meinem Create-Statement an die Referenz anfügen.

    @ErfinderDesRades Kannst du dir das mit OledB vielleicht genauer erklären als ich kleiner Anfänger ^^? interessieren würde mich schon ob das Fehlverhalten oder gewollt(und wenn welchen Nutzen das haben könnte xD) ist.

    Außerdem entschuldige ich mich für die etwas späte Antwort schaue immer nur ab und zu ins Forum um Sachen nachzulesen bekomme da nicht immer sofort die Benachrichtigung mit.

    Mit freundlichem Gruß
    Fabian
    Hmm - mehr als ich erklärt hab kann ich nicht erklären. Es gibt 2 Verfahren, wie man SqlParameter im CommandText darstellen kann.
    Die meisten SqlProvider benutzen die Syntax mit @paramName.
    Dabei muss man dann einem DBCommand-Objekt die Parameter zufügen, und zwar
    unter Angabe des im CommandText vorkommenden ParameterNamens, also sowas:

    VB.NET-Quellcode

    1. dim sql = "Select * from table where Column1=@param1 and Column2=@param2"
    2. dim cmd=new SqlCommand() With {.CommandText=sql}
    3. cmd.Parameters.AddWithValue("@param1", 55)
    4. cmd.Parameters.AddWithValue("@param2", 65)


    Access (und evtl. noch weitere, von denen ichs nicht weiss) hingegen unterstützt eine einfachere Syntax - nämlich Parameter sind ohne Namen - einfach durch ? dargestellt - sowas:

    VB.NET-Quellcode

    1. dim sql = "Select * from table where Column1=? and Column2=?"
    2. dim cmd=new SqlCommand() With {.CommandText=sql}
    3. cmd.Parameters.Add(New OleDbParameter() With {.Value = 55})
    4. cmd.Parameters.Add(New OleDbParameter() With {.Value = 65})
    Hier braucht man also einen ParameterNamen nicht anzugeben, stattdessen entscheidet die Reihenfolge, welcher OleDbParameter auf welches ? im CommandText angewendet wird.

    ErfinderDesRades schrieb:

    Hier braucht man also einen ParameterNamen nicht anzugeben, stattdessen entscheidet die Reihenfolge, welcher OleDbParameter auf welches ? im CommandText angewendet wird

    Das das dann mit anderen Zeichen als bloß "?" geht ist dann wohl ein Fehler.
    Dank dir die Zwei Methoden hast du gut erklärt denke das sollte es dann für diesen Thread gewesen sein :)