DB Null Abfrage wirft Fehler

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

Es gibt 20 Antworten in diesem Thema. Der letzte Beitrag () ist von MaHu1983.

    DB Null Abfrage wirft Fehler

    Moin!


    Ich habe ein kleines Problem, zu dem ich im Netz leider noch keine Lösung gefunden habe.

    Ich fülle ein Row Array mit einem Select-Befehl über eine Datatable.
    Dann prüfe ich Zeile für Zeile, ob sich die jeweils aktuelle DataRow schon in einer anderen Datatable befindet. Wenn nicht, erstelle ich eine neu Row in der zweiten Tabelle und schreibe die Felder aus der ersten Tabelle dort hinen. Ich kann die Row leider nicht einfach importieren, da es sich um komplett unterschiedliche Tabellen mit anderen Strukturen handelt.

    Jetzt haben aber einige Zellen in der ersten den Wert NULL bzw DBNull. Das versuche ich mit der Prüfung If Not IsDBNull(komRow.Rekl) Then (Zeile 18) abzufangen.
    Allerdings erscheint die Extension auch bei der Prüfung?? Ich möchte also schauen ob der die Zelle DBNull ist und bekomme einen Anpfiff, dass das nicht geht WEIL die Zelle DBNull ist.

    Ich hoffe, mir kann jemand dabei helfen. Unten habe ich noch den Code angefügt. Ich hoffe, dass ich den Code richtig in diesen Post eingebunden habe.

    Beste Grüße

    MaHu1983



    VB.NET-Quellcode

    1. Private Sub copyKomReport()
    2. Dim komFRow() As dsLifeReport.K_KomRepRow
    3. Dim lrRow() As dsLifeReport.tabLogBookRow
    4. Dim lrNewRow As dsLifeReport.tabLogBookRow
    5. komFRow = ds.K_KomRep.Select("Kom = '" & dgvKom.CurrentRow.Cells(0).Value & "'")
    6. For Each komRow As dsLifeReport.K_KomRepRow In komFRow
    7. lrRow = ds.tabLogBook.Select("Descr = '" & komRow.Kurztext & vbLf & komRow.Sachverhalt & "'")
    8. If lrRow.Length = 0 Then
    9. lrNewRow = ds.tabLogBook.NewRow
    10. With lrNewRow
    11. .DateOfExec = komRow.AngAm
    12. .NameTechnician = komRow.AngDurch
    13. .Descr = komRow.Kurztext & vbLf & komRow.Sachverhalt
    14. .Kom = komRow.Kom
    15. .CNo = dgvKom.CurrentRow.Cells(2).Value
    16. If Not IsDBNull(komRow.Rekl) Then
    17. .Rekla = Strings.Left(komRow.Rekl, 6)
    18. If Strings.Len(komRow.Rekl) > 8 Then
    19. .RekPos = Strings.Mid(komRow.Rekl, 8, Strings.Len(komRow.Rekl) - 7)
    20. Else
    21. .RekPos = Strings.Right(komRow.Rekl, 1)
    22. End If
    23. End If
    24. .ProgStat = "open"
    25. ds.tabLogBook.Rows.Add(lrNewRow)
    26. End With
    27. End If
    28. Next
    29. End Sub


    *Topic verschoben*

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Nope, leider nicht. Hab's gerade laufen lassen.

    Er schmeißt mir immer die Exception:

    Ein Ausnahmefehler des Typs "System.Data.StrongTypingException" ist in Life Report.exe aufgetreten.
    Zusätzliche Informationen: Der Wert für Spalte Rekl in Tabelle K_KomRep ist DBNull.

    Ich versteh das nicht ganz. Er meckert mich bei der Prüfung auf DBNull an, dass der Wert DBNull ist. :S
    Ich täte dir dringend 3 dringende Dinge empfehlen:
    1. schmeiss den Microsoft.VisualBasic - Namespace aus deim Projekt raus.
      Indem dieser Namespace dir ständig VB6-Schrott-Funktionenen per Intellisense unter die Finger spielt wird verhindert, dass du die wirklichen, objektorientierten Methoden von VB.Net überhaupt kennenlernst.
    2. Stell Option Strict On
      Lass den HIntergrund-Compiler seinen Job machen, und dich mit jeder Typ-Verwechslung konfrontieren, die dir unterläuft. So lernst du Datentypen zu unterscheiden und zu respektieren.
    3. Nutze das typisierte Dataset konsequent.
      In deim Code kommt eine ungute Vermischung typisierter und untypisierter Zugriffe vor. Wenn man weiss wie, sind die alle austauschbar durch streng typisierte Formulierungen. Letztere sind sicherer, lesbarer, und sogar auch bisserl schneller
    Zu 1. und 2.: Visual Studio - Empfohlene Einstellungen
    Zu 3.: codeproject.com/Articles/10351…ped-Dataset-for-Beginners
    Ist aber bisserl mehr (3 zusammenhängende Artikel), aber lohnt sich, zu lernen, weil das braucht man.
    Danke Erfinder des Rades. Bitte entschuldige meine verspätete Antwort, ich hab hier ne Weile nicht reingeschaut.

    Ich werde mir die Artikel auf jeden Fall mal durchlesen und versuchen mich konsequenter an die typisierten DS zu halten.

    Wie groß sollte eigentlich ein Dataset maximal sein? Gibt es Grenzen ab denen man in der Praxis das Projekt auf mehrere DS splittet

    MaHu1983 schrieb:

    Gibt es Grenzen ab denen man in der Praxis das Projekt auf mehrere DS splittet
    Ein DS liegt, wenn in gebrauch, zu jedem Zeitpunkt im Speicher. Dies bedeutet, dass das DS zuvor komplett aus einer XML in den RAM geladen werden muss. Grob kann man also 2 "Grenzen" nennen:
    1. Das starten der Anwendung wird durch das Laden des DS stark verzögert
    2. Der RAM vebrauch deiner Anwendung ist unverhältnismäßig hoch.
    Anstatt jedoch nun auf mehrere DS aufzusplitten wäre nun der Zeitpunkt auf Technologien wie z.B. SQLite umzusteigen. SQLite ist eine Dateibasierte Datenbank, die dir nur die Daten "in den Speicher lädt" die du auch anforderst. Da es für SQLite eine ADO.NET implementierung gibt, kannst du auch weiterhin mit deinen DataSets und -Tables arbeiten, hast jedoch einen kleineren RAM-Verbrauch und deine Anwendung kann quasi "Sofort" starten. Daten werden dann "On Demand" nachgeliefert. Unbenutzte Tabellen kann man dann wieder aufräumen.
    @EaranMaleasi
    Verstehe ich richtig? Das DATASET übernimmt nicht den kompletten Inhalt der SQLITE-Datenbank in den RAM?
    Das gilt dann wohl ja auch für Relationen, berechnete Felder etc.
    Welchen Einfluss hat das auf die Verarbeitungsgeschwindigkeit, insbesondere bei Suchanforderungen?

    MaHu1983 schrieb:

    Wie groß sollte eigentlich ein Dataset maximal sein?
    Heutzutage bringts einen Rechner auch nicht mehr zum Weinen, gschwind mal eine 20MB - Dataset-Datei zu laden.
    Das entspricht evtl. so 20-40000 Datensätzen, oder auch 100000, je nachdem.
    Mein Rechner lädt solch in 1s, und bei kleinen Datasets ist er sogar schneller als ein DbProvider Daten ranschaffen kann.
    Und sind die Daten erstmal geladen, ist die Verarbeitung unerreichbar schnell (weil ist ja alles im Speicher).

    Auch ist das kein so kleiner Schritt, die Dataset-Befüllung auf eine Db umzufrickeln - das sollte man sich gut überlegen, wann es dafür an der Zeit ist.

    Solange es nicht wirklich praktisch erforderlich ist, sollte man es lassen - insbesondere, wenn andere Baustellen noch garnet fertig sind - weil die Komplexität einer Anwendung steigt doch erheblich an.
    Also meine Daten liegen ja schon in einer DB.

    Ich meinte eigentlich eher die Anzahl der Tabellen in meinem typisierten Dataset. Im Moment merke ich, dass es schon ziemlich lange dauert, wenn ich Änderungen im Designer vornehme.
    Außerdem richtet der Designer die angelegten Tabellen auch nicht mehr aus. Ist ein ziemliches drunter und drüber in der grafischen Darstellung.

    Mein DS fasst jetzt ca. 30 - 40 Tables.
    Nein. Der Designer schiebt einfach meine ganzen Tables kreuz und quer durcheinander, übereinander und was weiß ich was.
    Anfangs sind die Tables noch sauber ausgerichtet worden. Ist aber eigentlich auch eher ein Komfort-Problem und nicht wirklich wichtig.

    Gehört ja auch nicht zum eigentlichen Thema dieses Threads.

    MaHu1983 schrieb:

    Komfort-Problem und nicht wirklich wichtig
    Ich find Komfort-Probleme durchaus sehr wichtig, und's nervt mich auch immer sehr, wenn der Dataset-Designer beim nächsten Öffnen die Tabellen nicht wieder so positioniert, wie ich sie mir in liebevoller Kleinarbeit zurechtgeschoben habe.
    Gelegentlich mache ich dann sogar Screenshot vom DS-Layout - für wenn ich nur nachgucken will reicht das ja.

    Auch das träge werden bei viele Tabellen kenn ich. Manchmal hilft Solution schließen und wieder neu öffnen.
    44 Tabellen findich aber auch sehr viel.
    Keine Ahnung, wie Microsoft sich das denkt - ist ja bekannt, dass im professionellen Bereich Datenbanken locker hunderte Tabellen enthalten können - dementsprechend müsste die Dataset-Technologie da eiglich mithalten können.

    Andererseits ist dein Projekt glaub nicht professionell, und womöglich hast du nur deswegen so viele Tabellen, weil dein Datenmodell nicht korrekt aufgebaut ist.



    Aber das ist alles erstmal nicht so wichtig.
    Wie weit bist du mit dem Umstellen auf Option Strict On, und dem Rauswerfen des MVB-Namespaces?
    Also professionell ist meine Anwendung sicher nicht. Sie entsteht zwar im Zuge meiner Arbeit und wird auch dort genutzt, trotzdem basiert mein Wissen auf Grundlagenlehrgängen, Selbststudien und Trial and Error ;)

    Auch mein Datenmodell ist nicht strikt bis in die 3. Form normalisiert.

    Da geht bestimmt noch was, aber alles nochmal von vorne... :S Never touch a (einigermaßen) running system :D
    Designmäßig schiele ich immer ein wenig wehmütig zu WPF. Vielleicht mach ich irgendwann mal den Masterreset. Wobei ich dann alle Daten vom jetzigen Modell in ein neues schaffen müsste. Und da schreiben jetzt immerhin schon täglich ca. 100 Leute rein.


    Strict on ist on und der MVB Namespace muss leider immer noch in der Anwendung Platz nehmen, weil ich nicht alles auf einmal ausbügeln kann. Ich muss mir ja in vielen Fällen erst die richtige Methode erarbeiten. Mühsam ernährt sich das Eichhörnchen.

    MaHu1983 schrieb:

    MVB Namespace muss leider immer noch in der Anwendung Platz nehmen, weil ich nicht alles auf einmal ausbügeln kann.
    Dassis so nicht richtig.
    In gegebenem Link (Post 9) stelle ich auch ein Konzept vor, wie man seine MVB-Sünden auch peu a peu ausbessern kann - genaugenommen Datei für Datei.
    Das lernt sich ratzfatz, weil ist zu 80% immer dasselbe, und nachfragen kann man ja ausserdem noch.