Berechnete Spalten im DataSet Designer

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

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von darkman203.

    Berechnete Spalten im DataSet Designer

    Hallo zusammen,es geht um das Thema Berechnete Spalten im DataSet Designer.
    ErfinderDesRades hatte dazu mal einen schönen Artikel erstellt:

    https://www.vb-paradise.de/index.php/Thread/57224-DataExpressions-Filter-und-berechnete-Spalten-im-Dataset/


    In der Zwischenzeit habe ich diese Möglichkeit auch rege genutzt, jetzt stoße ich allerdings an meine Grenzen.
    Folgendes Szenario habe ich:In der Tabelle Geräte sollen die Wartungskosten berechnet werden.
    Je mehr Geräte über einer längeren Laufzeit gewartet werden, desto grösser ist der Nachlass auf die Gesamtsumme.
    Ich benötige jetzt zur weiteren Berechnung den Nachlass. Siehe Tabelle im Anhang.

    Kann man sowas überhaupt mit Berechneten Spalten im DataSet lösen?
    Oder wie würdet Ihr das angehen?Schon mal danke für jegliche Anregung.

    Bilder

    • Nachlass.jpg

      55,03 kB, 1.187×188, 98 mal angesehen

    Erst mal danke für deine schnelle Antwort und sorry das ich mich erst jetzt melde.

    Es hatte sich leider ein Logik Fehler eingeschlichen wodurch die gesamte Zeit benötigt wurde, um dieses auszubessern.
    Naja das ist jetzt geschafft und nun zurück zu der ursprünglichen Frage.

    Letztendlich bin ich zu dem Schluss gekommen, dass es in diesem speziellen Fall keinen Sinn macht mit einer Expression zu arbeiten.
    Und unter anderem auch, da ich dann in Zukunft bei Änderungen bei der Rabatt-Berechnung (Vorgabe der Firma, wann z. B. wie viel Prozent gewährt wird) Probleme bekommen hätte.

    Der aktuelle Lösungsansatz sieht wie folgt aus:Es existiert eine Tabelle wo es die Spalten: Anzahl der Geräte – Laufzeit der Wartung – Rabatt in Prozent gibt.
    Diese durchlaufe ich jetzt einfach um den Rabatt Wert zu ermitteln.

    VB.NET-Quellcode

    1. ​
    2. bsRabattabelle.MoveFirst()
    4. For i As Integer = 0 To bsRabattabelle.Count - 1
    6. Dim ZeileRabatt = bsRabattabelle.At(Of dsStammkunden.RabattabelleRow)
    8. If _Laufzeit = ZeileRabatt.Jahre And Geräteanzahl = ZeileRabatt.GeräteAnzahl Then
    10. Return ZeileRabatt.Rabatt
    11. End If
    13. bsRabattabelle.Position += 1
    14. Next

    kannst du nicht dierekt die DataTable durchlaufen?
    Und eine BindingSource würde ich auf keinen Fall mit MoveNext durchlaufen - da gibts auch besseres.

    Und die Benamung 'Rabattabelle' für eine Entität ist sehr suboptimal. Optimal wäre einfach 'Rabatt'.
    Ich empfehle dir sehr, derlei Benamung-Fehler so früh als irgend möglich zu korrigieren (also sofort). Weil daraus ergibt sich ein Rattenschwanz an Folge-Umständlichkeiten der dich dein Leben lang verfolgt.

    Wenn ich Interesse wecken konnte, bitte nochmal nachfragen, dann kann ich auch mehr Informationen geben.

    ​kannst du nicht dierekt die DataTable durchlaufen?


    Ja ich denke ich könnte auch das DataTabel durchlaufen, aber welchen Vorteil hat dass gegenüber der Binding Source?


    ​Und eine BindingSource würde ich auf keinen Fall mit MoveNext durchlaufen - da gibts auch besseres.


    Meinst du eventuell einen Zähler, den ich hochzählen könnte? Aber wieso überhaupt ist MoveNext schlecht?


    ​Ich empfehle dir sehr, derlei Benamung-Fehler so früh als irgend möglich zu korrigieren (also sofort).


    Du hast auf jeden Fall mein Interesse geweckt, wieso ist die Benamung Rabattabelle schlecht?

    DataTable direkt durchlaufen:

    VB.NET-Quellcode

    1. For each ZeileRabatt as RabattabelleRow in dsStammkunden.Rabattabelle
    2. If _Laufzeit = ZeileRabatt.Jahre And Geräteanzahl = ZeileRabatt.GeräteAnzahl Then
    3. Return ZeileRabatt.Rabatt
    4. End If
    5. Next
    Mit Linq gehts noch einfacher (Einzeiler), aber so solls erstmal reichen.
    Da siehst du auch die SubOptimalität der Benamung:
    "ZeileRabatt as RabattabelleRow" suggeriert, dass ZeileRabatt eine Rabattabelle ist. Isses aber nicht, sondern ist nur ein Rabatt, und keine Tabelle.
    Also Entitäten singular benamen. Wenn plural benamt bekommst du auch Datensatz-Klassen generiert, die plural benamt sind - und das ist zum einen länger, zum anderen auch falsch.
    Ein Rabatt-Datensatz repräsentiert einen Rabatt, nicht eine Rabattabelle.

    BindingSource durchlaufen:
    Wenn du mit .MoveNext durchläufst, verstellt mit jedem Schritt auch ein evtl. angebundene Datagridview seine Selektion. Das frisst zum einen tw viel Performance durch massenhafte Gui-Updates, zum andern wäre ich als User nicht amused, wenn ein ButtonClick meinen ausgewählten Datensatz ans Ende des Grids verschiebt.

    Einfacher und ohne derlei Seiteneffekte:

    VB.NET-Quellcode

    1. For i As Integer = 0 To bsRabattabelle.Count - 1
    2. Dim ZeileRabatt = bsRabattabelle.At(Of dsStammkunden.RabattabelleRow)(i)
    3. If _Laufzeit = ZeileRabatt.Jahre And Geräteanzahl = ZeileRabatt.GeräteAnzahl Then
    4. Return ZeileRabatt.Rabatt
    5. End If
    6. Next

    Aber wie gesagt: Wenn dem keine Gründe entgegenstehen, verarbeite Daten im Dataset - nicht in BindingSources.

    Nochwas: Verzichte auf unnütze Leerzeilen. Solch macht Code auch bischen unleserlicher - schon weil dann nicht mehr so viel Code auf einem Bildschirm zu sehen ist.
    Und wenn man Leerzeilen wirklich nur zwischen Methoden einfügt, erhöht sich die Leserlichkeit weiter, weil dann bekommt eine Leerzeile eine sinnhafte Bedeutung, die dem menschlichem Auge unmittelbar einleuchtet: "aha - da hört eine Methode auf, und fängt die nächste an"

    DataTable direkt durchlaufen..., hatte ich so noch nicht auf dem Schirm, aber die Begründung warum das besser ist leuchtet mir ein. Werde ich anpassen und mir für die Zukunft merken.

    ​Da siehst du auch die SubOptimalität der Benamung

    Und dann ist es jetzt auch für mich ersichtlich wieso man sowas besser nicht machen sollte.

    Thx für die Infos, schön dass es hier Menschen gibt, die bereitwillig Ihr Wissen teilen. :)

Facebook
Telefonspende