Datenbindung / Filtern

  • VB.NET
  • .NET 4.5

SSL ist deaktiviert! Aktivieren Sie SSL für diese Sitzung, um eine sichere Verbindung herzustellen.

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

    Datenbindung / Filtern

    Hallo zusammen,

    Neben vielen anderen Problemen, habe ich auch noch eines bzgl. Datenbindungen (hier ein Datagridview) und Filtern.

    Bsp. (Daten werden von einer MSSQL-Datenbank gelesen)
    Ich habe eine Tabelle ADRESSEN die alle grundsätzlichen Adressdaten vorhält
    Ich habe eine Tabelle ANSPRECHPARTNER die alle Ansprechpartner einer Adresse vorhählt
    Also eine 1:n Beziehung

    Ich habe alles über den Designer gemacht. Projektdatenquelle hinzugefügt, ConnectionString, Tabelle(n) ausgewählt

    Über den Designer habe ich ein aus dem Dataset die Tabelle ADRESSEN auf ein Formular mittels Drag & Drop erstellt. Beim Starten werden die Daten gelesen und angezeigt.

    Dann bin ich in das Dataset > ADRESSEN und habe dort die ANSPRECHPARTNER gefunden (logisch). Und auch diese "Tabelle" habe ich als Datagridview auf das Formular gezogen. Klickt man also eine Adresse an, zeigt das zweite Grid die dazugehörigen Ansprechpartner.
    Siehe youtube.com/watch?v=YP_-eL6DdsA

    So, die Grids sind an die vom Designer erstellten Bindingssources gebunden. Die Bindings sind widerum an das Dataset mit dem jeweiligen DataMember gebunden.
    Die Ansprechpartner sind aber über die Relation (zwischen ADRESSEN und ANSPRECHPARTNER) an die ARESSENBindungsource gebunden. Logisch.
    Wenn ich jetzt ADRESSENBindingsource nach einem Feld filtere, zeigt das ADRESSENGrid nur die Adressen mit dem gewünschten Ergebnissen an. Macht Sinn, funktioniert.

    Aber wie bekomme ich es hin, nur innerhalb der ANSPRECHPARTNER zu suchen? So dass auch nur die Adressen mit den relevanten Ansprechpartnern angezeigt werden? Wenn ich über ANSPRECHPARTNER.Filter gehe, werden zwar nur die korrekten Ansprechpartner angezeigt, aber dennoch alle Adressen, und nicht nur die Adressen mit den gefundenen Ansprechpartnern.

    Ich habe mir eine Beiträge durchgelesen, aber mir kommt das "zu" schwierig und undurchsichtig vor.
    DataExpressions: Filter und berechnete Spalten im Dataset

    typisiertes Getchildrow filtern

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „rrobbyy“ ()

    rrobbyy schrieb:

    Aber wie bekomme ich es hin, nur innerhalb der ANSPRECHPARTNER zu suchen? So dass auch nur die Adressen mit den relevanten Ansprechpartnern angezeigt werden? Wenn ich über ANSPRECHPARTNER.Filter gehe, werden zwar nur die korrekten Ansprechpartner angezeigt, aber dennoch alle Adressen, und nicht nur die Adressen mit den gefundenen Ansprechpartnern.
    So funktioniert das niht.
    Schau dir die BindingSources an, und deren Properties im PropertyFenster (weißt du, was ich meine? - sonst fragen.)
    Da findest du, dass AddressenBindingSource die DataSource der AnsprechpartnerBindingSource ist - nicht umgekehrt.

    Man kann eine BindingSource als eine Daten-Abfrage verstehen.
    Also die AnsprechpartnerBindingSource fragt die AddressenBindingSource ab, deshalb bestimmt die Auswahl in AddressenBindingSource die Anzeige in AnsprechpartnerBindingSource.

    Es ist übrigens nicht der Filter, der die Anzeige der untergeordneten BindingSource bestimmt, sondern die Auswahl einer bestimmten ParentRow.
    Klar - filterst du auf nur eine ParentRow, dann wird die ja automatisch ausgewählt, aber dasselbe erreichst du auch ohne Filter - einfach durch Klicken ins Parent-Datagridview.



    Wie dem auch sei. Der Filter, den du dir scheints vorstellst ist viel komplizierter.
    Du willst ein paar Ansprechpartner erfiltern, und das ParentGrid soll dann darstellen, zu welchen Addressen die gehören.
    Was, wenn 2 Ansprechpartner auftreten, die zur selben Addresse gehören? Soll die Addresse dann 2 mal aufgeführt werden?
    aha...das ist doch mal eine Erklärung, die Sinn macht, auch wenn sie gerade mein kleines naives Weltbild jetzt nicht mehr so naiv ist..;)

    Es ist theoretisch durchaus möglich, dass ein AP in mehreren Firmen vorkommt, bspw. Berater (oder es heißt jemand nochmal genau so), die für bestimmte Aufgaben übernehmen. (ja, ich weiß, das Datenmodell könnte man auch hier etwas optimieren, aber es geht ja ums Prinzip) (

    Natürlich sollte es so sein, dass, wenn man nach einem AP sucht, auch nur einmal eine Adresse kommt. Es sei denn, den AP gibt's woanders auch, dann muss die weitere Adresse ebenfalls im ParentGrid aufgelistet werden.

    Der Einfachheit halber also lieber mehrere Grids, die unabhängig von einander die Ergebnisse zeigen? Gibt es eine Art Best-Practise?
    ich kann dein Datenmodell nicht mit deiner Problembeschreibung in Einklang bringen.

    Ich würd dir aber sehr raten, mach die Datenbank nochmal, und zwar unter Berücksichtigung einer sinnvollen Benamungsrichtlinie.
    Das vereinfacht das Verständnis eines Datenmodells und den Diskurs darüber exorbitant.
    Hier meine Empfehlungen:
    codeproject.com/Articles/10331…eginners#Model-Guidelines
    Dein Datenmodell dagegen scheint mir einfach nur wirr.

    Ein Knackpunkt ist, dass ich mir unter einem AddrKommu nichts vorstellen kann, und folglich auch unter nichts, was damit zusammen hängt.
    Aber das ist nur ein Punkt, und den erwähne ich nur, weil er in den 12 anderen Punkten nicht genügend deutlich hervorgehoben ist.
    Da steht zwar: "sprechend benamen" - aber ich fürchte, du weisst garnet, wie wörtlich ich das meine. Also meine Fragen sind wirklich:
    "Was ist ein AdressKommu?"
    "Wieso heißt es nicht so, wie was es ist?"
    Aber bitte darüber nicht die anderen 12 Punkte aus dem Auge verlieren!
    ähm...die Datenbank kann ich nicht neu machen, weil sie nicht von mir ist... weil es die DB einer lizenzierten und gekauften ERP-Lösung...

    ADRKOMMU beinhaltet alle Ansprechpartner.

    ich wollte lediglich für Outlook ein Add-In schreiben, welches die Adressdaten dort auswählbar, änderbar und durchsuchbar macht. Kappt ja auch alles, aber das Suchen ist halt in dieser Hinsicht schwer. Der Hersteller selbst bietet sowas nicht an. (Und ja, wie dürfen selbst Erweiterungen in die DB integrieren, aber es wird dafür halt kein Support übernommen)

    Warum die die Tabellen so nennen, tja...das wissen nicht mal die selbst. Aber anscheinend ist das im kommerziellen Bereich typisch. Unsere Solidworks EPDM Datenbank und MegaCAD-Datenbank haben auch kaum selbstsagende Tabellennamen.


    ADRESSEN hat alle Adressedaten
    ADRKOMMU hat alle Anspechpartner zu den Adressen (der Einfachheit halber hatte ich im Öffnungspost ANSPRECHPARTNER genannt (aber im Screenshot leider nicht umbenannt)

    Man sucht nach "Meier", und es kommen alle Adressen, wo in den Ansprechpartnern "Meier" steht, sowie auch die Adressen, die im Namen der Adresse "Meier" haben.

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

    Aha.
    Du Ärmster!

    rrobbyy schrieb:

    Man sucht nach "Meier", und es kommen alle Adressen, wo in den Ansprechpartnern "Meier" steht, sowie auch die Adressen, die im Namen der Adresse "Meier" haben.
    Mit solchen Einstreuungen bringste mich aber gleich durcheinander.
    Ist das jetzt eine neue, präzisere Problembeschreibung, oder ist das ein Feature, und bereits verfügbar?
    Sorry für die verspätete Antwort.
    Das ist m. E. das Feature. Das Problem ist die Umsetzung in dem bestehenden Formular ;)

    Wie würdest du hier am besten vorgehen? Gibt es überhaupt einen "richtigen Weg"?

    Wie du schriebst, geht das mit meinem bestehenden "Layout" nicht. Ich würde - aus rein praktikablen Gründen - ein weiteres Form erstellen, in der die Ansprechpartner und Adressen nicht mit einander verbunden und somit auch losgelöst mit dem Filter "durchsuchbar" sind.

    Möchte ja gerne an den Erfahrungen anderer teil haben...

    Danke übrigens für die Geduld! Aber ich verstehe, wenn dir langsam auch die ausgeht...

    rrobbyy schrieb:

    ErfinderDesRades schrieb:

    Ist das jetzt eine neue, präzisere Problembeschreibung, oder ist das ein Feature, und bereits verfügbar?
    Das ist m. E. das Feature. Das Problem ist die Umsetzung in dem bestehenden Formular
    Das ist widersprüchlich.
    Entweder es ist ein bereits verfügbares Feature, oder es ist eine Problembeschreibung. Beides kann es nicht sein.
    Natürlich kannst du sagen, es ist ein nicht verfügbares Feature, aber das wäre genau, was ich vorziehen würde als "Problem" zu bezeichnen und nicht als Feature.
    Soviel zur Begriffsverwirrung (ich hab nicht damit angefangen ;) )

    Also ich fasse es mal als gewünschtes Feature auf, und würde es etwas anners formulieren, weil dann technisch leichter machbar:

    Quellcode

    1. Es soll in Addresse.Name gesucht werden, und ggfs. mehrere Treffer angezeigt. Gleichzeitig soll in Ansprechpartner alle gesucht werden, die auf die Address-Treffer verweisen, mittels ihres Foreignkey
    Jo, das würde man mit 2 voneinander unabhängigen BindingSources umsetzen, denen man mit geeigneten Filter-Ausdrücken zuleibe rücken müsste.
    Also auf UserEingabe wäre zunächstmal der Adress-Filter zu bilden und anzuwenden. Dann aus der AddressBindingsource die Treffer herausholen, und deren Primkeys in einen FilterAusdruck für die AnsprechpartnerBindingSource einarbeiten.
    Etwa ein AnsprechpartnerBindingSource-FilterAusdruck könnte lauten:

    Quellcode

    1. "AddressID in (1,2,4,9)"
    Das wäre ein Filter, der alle Ansprechpartner findet, die auf eine der 4 addressierten Addressen verweisen.