using (SqlDataReader x_reader = x_ermittle_verpackungen_kunde.ExecuteReader())
{
cBestaende.Load(x_reader);
}
ist doch auch ok oder ist
Nein, das befüllen der DataTable ist das Problem, die DT ist ein Speichermonster das ziemlich langsam ist.
Jeder Reportgenerator seit Eonen kann auch mit Klassen umgehen, also ist das arbeiten mit Klassen und deren Listen die deutlich schnellere und einfachere alternative.
Ausserdem ist es typsicher.
var engine = new RazorLightEngineBuilder()
.UseFileSystemProject("C:/RootFolder/With/YourTemplates")
.UseMemoryCachingProvider()
.Build();
var model = new {Name = "John Doe"};
string result = await engine.CompileRenderAsync("Subfolder/View.cshtml", model);
Da hast du wohl etwas komplett falsch verstanden.
Der Sql Client ist dazu da die DataTable vom MS SqlServer her zu befüllen, du kannst damit nicht in der DataTable suchen.
Bitte nicht so machen.
Die Daten gehören nicht in das DGV sondern in eine Liste/DataTable.
Damit die jeweilige Column auch weis welche Spalte der DataTable gemeint ist, musst du nur MappingName setzen und dafür muss die Spalte natürlich auch einen namen haben
Ich habe das mal vor Jahren direkt mit SignalR gemacht.
Man kann ja schließlich auch eine Payload mitgeben.
Also nicht nur alle benachrichtigen das eine Änderung vorhanden ist, sondern diese auch gleich mit senden.
Macht natürlich nur Sinn bei "kleinen" Payloads.
Das einlesen einer TextDatei in eine List<Messwert> ist deutlich schneller und speicherschonender als eine Speicherfressende DataTable zu nehmen, und auch nicht komplizierter.
Access ist keine Datenbank, sondern eine Datendatei, die durch den Jet-Treiber ( OleDb ) interpretiert wird. Jede Operation geht über die ganze Datei.
Wenn du eine echte DB wie z.b. SQLite benutzen würdest, wäre das wahrscheinlich in millisekunden passiert.
Und Du liesst hier die ganze DB vorher in eine DataTable, warum?
Naja, eine schleife und 2 strings die du anschließend nur noch zusammen an die Filter property "hängst" ist doch nicht so schwer.
Man baut übrigens im ersten Teil den Teil ein, den der User sieht, und da schreibt man den Filetyp aus.
Geht recht einfach mit einer abgeleiteten ObservableCollection ( lässt sich einfacher überschreiben ) die einen Windows.Forms.Timer hat.
Dann die einzelnen Aktionen abfangen und ggf den Timer starten. Der Timer macht dann die Events im UI Thread.
Für die UI ist es selten nötig in millisekunden anzuzeigen.
Aber das ist ein weiterer Grund mal WPF anzuschauen.
Die Notwendigkeit der Prüfung des Invoke habe ich unterlassen, da das Ergebnis auf jeden Fall true ist. Auslesen aus 'nem DGV geht ohne, einschreiben nur mit.
Bitte NIEMALS die Daten in ein UI Control hineinfrickeln, sondern Databinding benutzen.
Dazu auch [Artikel] Drei-Schichten-Architektur beachten.
Ich muss kurz nachfragen, weil ich ehrlich den Button nicht kenn:
"Zu meinem letzten Beitrag" ist nen relativ deutlicher Text; aber er ist auch wirklich direkt zum letzten Beitrag gegangen oder zu einer Liste von Beiträgen?
Es waren im Grunde 2 Links, einmal direkt mein letzter Beitrag ( was aber auf deine Beiträge als liste verweiste ) und das Datum/Uhrzeit deines wirklich letzten Beitrags was dann auch dort hin sprang