Nur aktivierte Datensätze aus Datenbank anzeigen

  • VB.NET
  • .NET (FX) 4.0

Es gibt 67 Antworten in diesem Thema. Der letzte Beitrag () ist von frifri.

    Nur aktivierte Datensätze aus Datenbank anzeigen

    Servus, Grüezi und Hallo,

    Ich bastele gerade an einer Programmoberfläche welch mir und meinen beiden Mitarbeitern die Arbeit im Büro erleichtern sollen. Hauptsächlich geht es darum die Abläufe bei uns auf Arbeit zu beschleunigen und vor allem um eine einheitliche Struktur, welche eine effiziente Suche nach Formularen, Zeichnungen... also Daten erlaubt. Bis jetzt war es so das alles in einer gewissen Grundordnung und auch recht umfangreich in Papierform archiviert wurde. Dies erfordert bei der Recherche meiner Meinung nach zu viel Zeit. ( Wir haben einen Raum voll Ordner so viel dazu). Nachdem nun Anfang diesen Jahres sowohl der Geschäftsführer als auch die Sekretärin in den wohlverdienten Ruhestand gegangen sind, sehe ich die Zeit für gekommen um da einiges zu ändern.
    Soviel zu meiner Motivation.

    Jetzt mein erstes Problem. Ich habe ein Kundendataset in dem alle unsere Kunden mit Kundennummern und Adressen enthalten sind. Der Kreis der Kunden die wir regelmäßig beliefern ist allerdings eher gering. Daher habe ich eine Boolsche Variable (Stammkunde ja/nein) ins Dataset mit eingefügt. Jetzt will ich in meinem Formular in einer Combobox nur die Kundendaten der Stammkunden angezeigt bekommen. Wie geht das. Im Combobox Aufgaben Menü gibt es den Punkt Abfrage hinzufügen. Geht darüber was?

    MfG Biesdorftier

    Hallo und willkommen im Forum :thumbsup:

    Hast du ein normales DataSet und du willst Daten in die Combobox, die eine bestimmte Eigenschaft haben?

    Ich mache das mit LINQ:

    VB.NET-Quellcode

    1. ComboBox1.DataSource= (From k in DataSet1.Kunden Where k.IsStammkunde = True).ToList
    2. ComboBox1.DisplayMember="Name" 'wenn die Spalte so heißt

    Biesdorftier schrieb:

    sehe ich die Zeit für gekommen um da einiges zu ändern

    Das ist eine gute Idee.
    Das Du selbst eine Software für die Firma schreibst kann eine gute Idee sein - muss aber nicht.
    Dein Problem und Deine Fragestellung zeigt mir, dass es vermutlich viel schneller und effizienter gehen würde, wenn Ihr Euch das machen lasst.
    Das tut nur einmal weh - funktioniert dann aber auch richtig.
    Für diese Entscheidung (die Du durchbringen musst) werden Dich Deine Mitarbeiter lieben - glaube mir :) .

    Viele Grüße,
    Bruno

    PS: Biesdorf - Berlin?

    ich würd da nicht gleich mit Linq drauf losgehen: Combo ganz normal an eine BindingSource binden, und BindingSource.Filter="Stammkunde = True" setzen - kannste sogar im Designer.
    @TE: in Datenbänkerei-Einstieg wird die große Überraschung zum DB-Einstieg verkauft: keine DB anlegen!! 8| , und in den weiterführenden Links gehts dann zur Sache.

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

    Weshalb sollte man keine Datenbank verwenden? Wenn der Einsatz einer Datenbank angemessen und gerechtfertigt ist, dann sehe ich keinen Grund keine Datenbank zu verwenden. Wobei Datenbank selbst verständlich auch ein sehr, sehr, sehr weiter Begriff ist. Und das mit dem Filter ist halt auch so ne Sache. Dieser Filter ist nunmal ein String. Und hatte auch schon das Problem, dass ich den Spaltennamen in einer Datenbank geändert habe und anschließend vergessen habe das dort umzustellen. Außerdem läuft im Falle einer Datenbank die Linq Abfrage (bei richtigem Einsatz) auf der Datenbank. Dies verringert schonmal die Netzwerkbelastung, da so nur die wirklich notwendigen Daten übertragen werden (je nach dem ob die Datenbank lokal läuft oder nicht). Außerdem sind Datenbanken auf solche Abfragen optimiert und können diese in den aller meisten Fällen schneller verarbeiten.
    Grundsätzlich bin ich leider erst viel zu spät darauf gekommen welche Vorteile von einfachen Abfragen mal abgesehen Linq bietet. Hätte mir viele Stunden umschreiben sparen können. Bin mittlerweile schon so weit, dass ich komplexe Auswertungen und Statistiken zu 100% auf der Datenbank rechnen lasse. Je nach dem in einer Abfrage (mit Linq geht das ja recht gut) oder im Form einer Prozedur.
    Wobei bei so einer einfachen Abfrage die Abfrage im Filter der BindingSource noch akzeptabel ist. Je nach Datenmenge würde ich dies jedoch trotzdem die Datenbank machen lassen. Ist immerhin schneller und schont das Netzwerk.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    Das Warum begründe ich doch ausführlich im gegebenen Link. Sind die dort angegebenen Gründe nicht verständlich oder stichhaltig?


    Übrigens, Ich kanns im Grunde selbst nicht mehr hören. ;(
    Aber es ist wie mit Option Strict On!
    und böse Funktionen
    und TryCatch ist ein heißes Eisen:
    Es muss jedem einzelnen ausführlich nahegelegt werden - meist sogar mehrmals, und mit Nachdruck, und oft auch erst beim Ende der Sackgasse. Weil von selbst kommt da niemand drauf, und die meisten haben große Mühe, von Denk-Gewohnheiten abzugehen, so gut begründet es auch sein mag.
    Und trotzdem ists inhaltlich richtig, und deswegen muss halt ständig drauf rumgeritten werden, tut mir leid (und nervt mich auch selber).

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ErfinderDesRades“ ()

    diylab schrieb:

    Weshalb sollte man keine Datenbank verwenden?
    verstehe ich als Frage.
    Falls es nur eine rethorische Frage war, naja, inhaltlich stimme ich ja voll und ganz zu, nämlich:

    thefiloe schrieb:

    Wenn der Einsatz einer Datenbank angemessen und gerechtfertigt ist, dann sehe ich keinen Grund keine Datenbank zu verwenden.
    Das ist ja im Grunde banal. Natürlich muss man eine DB nehmens, wenns angemesen und gerechtfertigt ist - ja was denn sonst?

    Du kannst später immernoch OHNE PROBLEME von einem DataSet auf eine SQL DB oder ähnliches umsteigen...

    Also hat finde ich EdR schon recht wenn er jedem versucht mit nachdruck klarzumachen.

    Und wenn euch seine Beiträge nicht passen bleibt euch immernoch die Wahl Ihn zu ignorieren.
    Dazu kommt, das er meisten der einzigste ist der einem hier im Forum hilft.

    Also bitte, macht sinnvolle und hilfreiche Beiträge oder Schnauze. Wenn du begründen kannst wieso eine vollwertige SQL Datenbank in diesem Fall besser ist, mach es!

    shaebich schrieb:

    Du kannst später immernoch OHNE PROBLEME von einem DataSet auf eine SQL DB oder ähnliches umsteigen...

    Wenn es aber ein kleines bisschen mehr zur Sache geht - und das ist Erfahrungsgemäß in sehr vielen Fällen und unabhängig von der Projektgröße und Multiuserfähigkeit so, dann ist es keine schlechte Idee, die meisten Funktionalitäten in Form von Prozeduren, Funktionen, Views und Triggern direkt in der DB laufen zu lassen - Zeit ist Geld.
    Viel Spaß dann beim Migrieren der DataSets und dem Müllcode, den VS dabei produziert.

    Die Daten werden in einer XML-Datei vorgehalten. Die DataSet-Klasse verfügt über die Methoden .ReadXML(path), .WriteXML(path). Perfekt geeignet für Projekte mit überschaubarer Größe.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    frifri schrieb:

    Woher kommen denn die Daten?
    Das eigliche Ado.Net-Konzept sieht DataAdapter vor, die Daten aus Datenbank-Tabellen holen oder zurückschreiben. Hierbei greift die Änderungsverfolgung des Datasets, und für Mehrbenutzer-Systeme ist sogar eine Exception vorgesehen, die Alarm gibt, wenn mehrere User sich beim Rückspeichern desselben Datensatzes in die Quere kommen.

    Der Witz nu ist, dass MS dem Dataset die kleinen schnuckligen Methoden .WriteXml und .ReadXml spendiert hat.
    Damit kann man ein Dataset komplett auch direkt auf Platte schreiben und lesen - ohne Datenbank.

    Das ist eine ungeheure Vereinfachung denn so braucht man keine Datenbank, und die o.g. DataAdapter muss man auch sorgfältigst konfigurieren, und jeder ist nur für eine Tabelle zuständig, und man muss beim Abspeichern auch eine kollisionsfreie Reihenfolge der Tabellen einhalten, und wenn man selektiv einzelne Tabellen oder auch nur Auszüge daraus einliest, ist wiederum die Daten-Konsistenz im Dataset in Gefahr, und und und...

    Also die "Komplikationen" der DataAdapter sind nicht nur problematisch - das sind ja im Grunde mächtige Features, ohne die man Mehrbenutzer-Systeme oder wirklich fette Datenbanken gar nicht in den Griff bekäme.
    Nur als Anfänger, für Kleinkram und zur Entwicklungszeit kann dank .Read-/.Write-Xml komplett drauf verzichtet werden.
    Das mitte "Entwicklungszeit" ist nu auch interessant: Während dieser ändert sich ein Datenmodell häufig, und viele Daten liegen normalerweise noch längst noch nicht vor.
    Also empfehle ich immer dringend, DatasetOnly zu entwickeln, und erst wenn alles steht, und erst bei tatsächlichem Vorliegen riesiger Datenbestände oder bei tatsächlichem Vorliegen eines Mehrbenutzersystems, also dann ganz am Ende das kleine .ReadXml auszutauschen durch die komplexe aber auch mächtige Persistenz mittels DataAdapter.

    Das ist im Grunde nix als die Anwendung der Rules Of Optimization

    Der andere Witz ist, dass man nach Ado.Net die Dataset-Technologie ohnehin beherrschen muss. Also ob du nun DatasetOnly entwickelst, oder dir gleich eine DB ans Bein bindest ist dasselbe: Daten werden ins Dataset geladen und dort wird verarbeitet, und daran wird gebunden.
    Also man verschenkt nicht eine Zeile Code, wenn man DatasetOnly entwickelt und später nachrüstet.
    Naja - ist übertrieben: Natürlich baut man einzelne Zeilen der DatasetOnly-Primitiv-Lösung ab, wenn man auf Speicher-Ersparnis optimiert: Etwa das Setzen eines BindingSource-Filters (eine Zeile) könnte man austauschen durch eine DataAdapter-Abfrage, die den Filter mittels Sql gewissermassen in die Datenbank verlegt. (Wobei dann aber zT erhebliche weitere Vorkehrungen zu treffen sind.)

    Aber so geht Optimieren: Erst unoptimiert, aber mit sauberer Architektur lauffähig machen, und erst ganz zuletzt und nur an den Brennpunkten sich die zusätzliche Komplexität der Optimierung ans Bein binden.

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

    Also, ich komme nicht umhin, mit meinem profunden Halbwissen auch noch meinen Senf dazuzugeben:

    Dieses Forum richtet sich nach meinem Empfinden NICHT an die DB-Profis, und schon garnicht an die, die sich dafür halten.
    Korrigiert mich bitte, aber das professionelle Aufsetzen und Betreiben einer IBM-DB2 Datenbank, um dort CERN-Ergebnisdaten aufzunehmen und auszuwerten, sollte ebensowenig Gegenstand dieser Plattform sein, wie die Entwicklung von Systemen wie SAP, mit denen die Geschäftsprozesse globaler Unternehmen optimiert werden.

    Hier in diesem Forum haben viele Einsteiger und Umsteiger eine Plattform gefunden, und dieses Niveau sollte man unbedingt im Auge behalten und unterstützen. Für die Hilfesuchenden ist es kontraproduktiv, wenn ständig gemosert wird: "Warum denn Trabbi fahren, es gibt ja Formel1-Boliden, und warum mit weniger zufrieden geben". Diese Leute haben aber auch garnix verstanden. Wenn sie sich mit Ihrem 15/tel, oder meinetwegen sogar 1/2-Wissen profilieren wollen, sollen sie sich die richtige Plattform dafür suchen. MSDN oder auch CodeProject ist dann sicher keine schlechte Wahl. Aber dort sind eben die wirklichen Profis unterwegs ... da wird's dann schon schwer, sich in den Vordergrund zu spielen.

    Ich persönlich bin froh darüber, das es in DIESEM Forum Mitglieder gibt (und ErfinderDesRades ist eins davon, aber wirklich nicht der Einzige) die versuchen, neben Problemlösungen auch einen gewissen Lerneffekt zu generieren.

    Dafür danke ich diesen "Altruisten" ganz herztlich. Weiter so.

Facebook
Telefonspende