Von einem Sub im Modul auf gleichlautende Controls in verschiedenen Formen zugreifen

  • VB.NET

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

    Hanuta schrieb:

    Änderungen (myTypedRow.XY = "def") werden dann auch ins Dataset übernommen nehme ich an?!
    ja

    Hanuta schrieb:

    Und wie würdest Du ein count realisieren?

    VB.NET-Quellcode

    1. dim count = myTypedTable.Count()

    Hanuta schrieb:

    es gibt ein angebundenes DGV. Das ist zu Debugzwecken drin, meist versteckt, wird aber erst beim Öffnen des DGVs mittels " TableDataGridView.DataSource = TableBindingSource" befüllt.
    Wie gesagt: Gut möglich, dass diese Zuweisung der BindingSource die 1-3s ausmacht.
    Zu deine Form_Load-Schnipsel: Sieht soweit ok aus, nur das .ClearBeforeFill ist eine Einstellung, die man im FormDesigner tätigen sollte - nicht im Code. Ist einfach unsinnig bei jedem Update die Einstellung zu erneuern - die ändert sich ja nicht.

    Hanuta schrieb:

    Gibt es eigentlich eine Möglichkeit, einen Clienten erkennen zu lassen, ob sich das Dataset, was er geladen hat, auf dem Server in der Zwischenzeit geändert wurde?
    Nichts, was wirklich praktisch wäre.
    Aber es gibt mhrere Möglichkeiten, aber jede ist eine Baustelle für sich, es zu programmieren.

    Hanuta schrieb:

    Parallelitätsverletzung
    Die Parallelitäts-Verletzung entsteht, wenn der zu ändernde Datensatz bereits geändert vorgefunden wird.
    Ich vermute, das hast du selbst verzapft, indem du erst die DataTable befüllst, dann den Datensatz in der DB mittels deim DbWrite-Dingens änderst, dann den Datensatz auch im Dataset änderst, und dann mit .Update() rückschreiben will.
    DataAdapter ist so schlau, dasser merkt, dass da zwischenzeitlich dran rumgefummelt wurde, und wirft dn Fehler.
    (Dein DbWrite merkt das sicherlich nicht, und bügelt einfach drüber.)

    @RodFromGermany
    Dein Angebot ist superklasse, vielen Dank. Aber Cheffe ist da komplett anderer Meinung, ich darf da leider nichts rausgeben, egal wie abgespeckt :(

    @ErfinderDesRades
    Ok, das clear verschiebe ich mal.
    Die Parallelitäts-Verletzung ist genau so, wie Du sagst, eindeutig reproduzierbar.

    Aber das ist doch das absolute KO-Kriterium für ein Dataset, was gleichzeitig von verschiedenen Clients geändert wird?! Oder übersehe ich da eine Möglichkeit?

    Wie gesagt, mehrere Clienten (um 20), alle schreiben oder lesen kontinuierlich in der DB. Das sehe ich grade als Vorteil meines DB_Write bzw. Reads. Es kommen halt immer die aktuellen Datensätze aus und in die DB.
    Mit dem Count verstehe ich noch nicht wirklich. Ich möchte ja nicht die absolute Zahl der Datensätze haben, sondern wissen wie oft in den DS XY="abc" ist.
    MeinDataSet.MyTable.ToList(Function(rw) rw.XY = "abc").count und ähnliches habe ich grade mal äußerst erfolglos getestet.
    Brauch' ich die?

    ich sehe das eher als KO für dein DBWrite.
    Also einem Benutzer ist das nicht zumutbar, dass ein Datensatz, den er grade eingespeichert zu haben glaubt, von einem anderen Bearbeiter dann wirklich abgespeichert wird.

    Aber diese Paralellitäts-Sicherung des DataAdapters kann man auch abschalten.

    zum Count:

    VB.NET-Quellcode

    1. MeinDataSet.MyTable.Where(Function(rw) rw.XY = "abc").count

    Ja, das wäre wirklich selten dämlich! Nein, das kann hier nicht passieren, keiner arbeitet am gleichen Datensatz. Das Prog poppt bei einem angemeldeten User auf, sobald eine Arbeit anliegt. Und dann muss der DB schnell gesagt werden, dass diese Arbeit grad in Arbeit ist (hach, ich liebe gutes Deutsch), bevor es beim nächsten User erscheint.
    Aber das lässt sich abschalten? Ach ne, das würde dann wirklich Chaos geben wenn jeder Client die komplette DB zurückschreiben würde. Wenn, dann ja nur den DS, den er grad bearbeitet hat.
    Also, mit anderen Worten - das an sich wirklich feine Dataset ist nicht netzwerkfähig...
    Brauch' ich die?

    Hanuta schrieb:

    Also, mit anderen Worten - das an sich wirklich feine Dataset ist nicht netzwerkfähig...
    Ich weiss jetzt nicht, wie du grad zu diesem Schluss kommst.
    Multi-User-Unterstützung ('Netzwerkfähigkeit' würde ich das nicht nennen) ist keine Frage des Datenmodells, sondern eine Frage, wie du das Anwenderprogramm (alias 'Client', 'Frontend') programmierst.
    Prinzipiell muss die Technologie natürlich alles können.
    Aber konkret dein Proggi stellt dem User natürlich nur Funktionen zur Verfügung, die sinnvoll sind und nix kaputt machen.
    Da gibts verschiedene Strategien und verschieden aufwändig (ich liebe guteres Deutsch).

    Moin,
    sorry, ich war verhindert.
    Ja, Multi-User hört sich besser an, auch wenn es ein Wort gutestes Deutsch weniger ist.
    Also bin ich eigentlich gezwungen, den Update-Befehl des Datasets händisch anzupassen. Damit könnte ich dann doch verhindern, dass ungewünschte Datenfelder beim Update mit aktualisiert werden. Wäre mir aber zu viel Aktion und vor allem bin ich vergesslich - eines Tages füge ich eine neue Spalte in meine Table ein und lass den Update-Befehl aktualisieren, *bums* und schon wieder wird alles überschrieben.
    Ne, ich glaube dass in meinem Fall der beste Weg wohl sein wird, dass ich das Dataset nur zum lesen nutze. Alles was aktualisiert werden muss, geht dann über mein DB_Write-Konstrukt...

    Leute, ich danke euch vielmals, auch wenn wir hier ein wenig von Höckchen auf Stöckchen gekommen sind (kennt den Spruch überhaupt jemand jenseits des Potts?). Habe wieder viel gelernt - und darum gehts hier ja!!

    So long
    Brauch' ich die?

Facebook
Telefonspende