kommt immer darauf an was Du in deine Class1 oder Subclass so treibst. Wenn das wirklich wie dargestellt nur simple POCOS sind, sollte das tatsächlich so funktionieren.
Die erste Instanz würde aber trotzdem noch eine weile im Speicher verbleiben, bis der Garbage Collector sich bemüht das Ding mal endgültig aus dem Speicher zu werfen.
Hast Du nun irgendwelche Resourcen gebunden, die nicht vernünftig abgeräumt wurden, kann es durchaus zu Exceptions kommen.
Ausserdem kann man noch sehr böse Sachen in Konstruktor oder Property Machen die solche Sachen hervorrufen. Aber wie T-Virus schon schreibt ohne Exception oder Code kann man hier nur raten.
Außerdem ist es jawohl Geschmackssache ob man Daten eher in einer Liste als einer DataTable verarbeitet.
Nein. Ich würde jeden Kollegen der was neues (Du machst den Teil ja neu) mit DataTable anfängt vierteilen. Weil ich das im Zweifelsfall vielleicht mal warten müsste. Datatable(genauso wie die typisierte Variante) gehören in die Mottenkiste.
Nein ich meine schon die structs. Ich müsste jetzt tatsächlich lange nachdenken um mich zu erinnern, wann ich das letzte mal structs benutzt habe. Das Problem dabei ist ja, wenn du nicht explizit mit ref arbeitest, gibst Du immer eine Kopie von dem Object weiter. Wenn Du versuchst dann ein two-way binding zu benutzen, arbeitest Du im zweifelsfall nur auf der Kopie.
Benutze bitte in deinem eigenen Interesse besser POCO´s zur Datenhaltung.
wenn das möglich ist, dann nur mit fiesen hacks. Schreib es um. Ich will gar nicht wissen was es für Auswirkungen hat, wenn man versucht structs an die Gui zu binden.
@_Cashisclay Beim ersten Beispiel hattest Du keine Parameter. Das war noch in Ordnung. In deinem 2. Beispiel lötest Du die Parameter direkt per String concat in den Sql.
Das ist in mehreren Situationen fatal. Wobei Sql Injection wohl der grösste minus punkt ist.
Ein anderer ist z.B. die fehlerbehaftete Umwandlung von div. Datentypen nach string und zurück.
ich vermute allerdings er sucht eigentlich nur nach einer Möglichkeit einen Multiline String zu benutzen.
var sql = @"
Select *
FROM Zeiterfassung.dbo.Mitarbeiter
";
Und was ist an reinem Sql unsauber? Der Zugriff mit dem EF ist natürlich schöner, aber überall da wo es auf Performance ankommt, gerade da wo es über mehrere Tabellen geht, kommt das EF einfach nicht mit. Und ich habe es oft versucht :(
in deinen Account musst Du nicht. Du musst nur unter Help -> Register Product den Lizenz Schlüssel eingeben. Ob dieser allerdings Offline aktiviert oder im Hintergrund im Netz Validiert wird, ist mir nicht bekannt.
bisher hatte ich nur auf dem Schirm das .Result eine eventuelle Exception in eine AggregateException kapselt. Das dieser Aufruf aber Deadlock anfälliger ist als GetAwaiter habe ich noch nicht gehört.
Also um nochmals auf das Beispiel mit der Wäsche zurückzukommen.
Was wir machen ist, eine Maschine anmachen, dann zur nächsten gehen um die anzumachen, dann.... etc.
Das Waschen erfolgt hier imho parallel. Das Probleme mit dieser herangehensweise ist nicht das Waschen selber (Warten auf die Datenbank antwort), sondern das befüllen, entleeren (z.B. Mappen von Objekten) Das machst Du in diesem Fall alleine, also nacheinander.
Das würde sich wiederum nur mit "echter" Parallelität lösen lassen. Sprich mit Parallel.ForEach, Task.StartNew, Task.Run oder wie sie alle heißen.
Deshalb habe ich das Beispiel mit den Delays auch genau so gewählt.
ich glaube wir reden hier aneinander vorbei.
Nehmen wir an ich hätte 3 Datenbanken die ich durch einen update befehl aktualisiere der jeweils 3 sekunden dauert (Replace für das Task Delay, also pures i/o).
Würdet ihr also sagen das ich nach dem obigen snippet dann 9 sekunden warte, bis alle fertig sind?
Wenns keine parallelität hier gäbe, müsste die Reihenfolge eine andere sein. Natürlich nur wenn die Hauptaufgabe darin besteht auf irgendwas zu warten (I/O). 3 Threads werden hier natürlich nicht gestartet.
Das was du da machst (asynchrone Aufrufe parallel ausführen) ist nicht immer zulässig.
@Sir Rufo
Kannst Du das einmal ein wenig genauer erläutern? In ähnlicher Form setze ich das auch öfter ein, ein Problem damit konnte ich noch nicht feststellen. Oder spielst Du hier auf die normalen Probleme mit Parallelität an?
Nur so zum Verständnis.. Abt scheint es so zu verstehen das Du eine Email an 500 Empfänger schickst. Scheint mir bei Rechnungen aber eher unwarscheinlich. Mit 500 in einem Lauf meinst Du 500 Emails an 1 (oder 2 oder 3) Adresse(n) in einer Schleife oder?
Dann kannst Du allerdings durch loggen oder debuggen feststellen welche das genau sind, und selbst testweise Emails schicken.
Auch möglich sind Regeln des sendenen smtp Servers, amok laufende Antiviren programme, sendelimits etc.
Gibts eine InnerException?
Zu guter letzt könnte man sich mit dem Wireshark dazwischen hängen(bzw Fiddler? kann Fiddler smtp?) um die genaue Antwort des Servers zu bekommen.
Vermutlich wird es klappen wenn Du das selectedItem Property des Grids an ein Property in deinem VM bindest (nicht vergessen hier PropertyChanged aufrufen!)
Dann bindest du mit deiner Combobox nicht mehr direkt auf das SelectedItem Property deines Grids sondern auf das neue im VM.
Du tust dich sehr viel leichter in WPF, wenn alle Datenelemente die Du bindest, direkt INotifyPropertyChanged implementieren. (Kann man ja auch genrerieren lassen ;) )
Dictionary ist in deinem Fall nicht die richtige Klasse (wenn ich richtig vermute).
So könntest Du auch nur einen Bob oder eine Johanna haben. Soll ja Leute mit gleichem Vornamen geben ;)
Du solltest versuchen dir erstmal ein Grundlagen Buch vorzunehmen. Ansonsten endet das in großen Frust.
Du versuchst auf das dictionary mit einem Index (people[1]) zuzugreifen. Das geht so nicht. Dictionarys arbeiten mit Keys, in deinem Fall "Bob" oder "Johanna".
gibt es einen Grund warum Du nicht die OracleConnection benutzt?
Zitat
If the Devart.Data.Universal.UniConnection goes out of scope, it is not closed. Therefore, you must explicitly close the connection by calling Close.
hört sich für mich erstmal so an, als wenn man diese Connection nur mit bedacht wählen sollte. Und ob hier IDisposable (absichtlich) nicht richtig implementiert ist, ist auch fraglich.
Andererseits ruftst du ja auch explizit close auf.
ich denke du vergisst in deiner MessageCallback Methode udpalg zu inkrementieren.
Ist aber auch gefährlich, denn wenn ein Udp Packet nicht ankommt oder der sender neu gestartet wird, kommt deine Logik vollkommen durcheinander.
leider können wir aus deinem Stück Code nicht sehen, was am Ende herauskommen soll. Ist ein wenig wie zu versuchen in eine Glaskugel zu schauen. Wenn Du noch eine genauere Antwort brauchst, fürchte ich, musst Du etwas weiter Ausholen.
Trotzdem sieht es mir so aus als könnten Interfaces hier nützlich sein.