Klingt danach, das dein UserControl ohne den Default Konstruktor daher kommt.
Vermutlich willst du irgendwelche Parameter an deinen Konstruktor geben, was bei Controls im Designer nicht funktioniert.
Warum liest du nicht die Doku dazu um deine Frage zu beantworten?
Da steht im Grunde unter Hinweis welchen Zweck die BindingSource erfüllt und wofür du diese nutzen solltest.
Anbei braucht man für die Datenbindung keine Datenbank.
Es braucht nur i.d.R. eine Collection bzw. entsprechende DataSource von der dann die Daten geholt werden können.
Dies kann eine Liste, Array oder auch eine auf Collections basierte Eigenkreation sein.
Wenn du dich in die Grundlagen eingearbeitest hast und die Dokus von Microsoft liest, dann wird es auch einfacher und du musst nicht mehr blind basteln.
Spart dir auf lange Sicht Zeit und Mühe.
Mein Ansatz wäre auch eine eigene Klasse anzulegen, die dann deine Daten intern verwaltet und dir eben für die Abfragen entsprechende Methoden liefert.
Du musst dann schauen ob ein einfaches Dictionary<bla, blub> reicht oder ob du ggf. als Value des Dictionary noch ein weitere Such Struktur benötigst.
Dies hängt aber davon ab wie gut deine Struktur in Schlüssel aufteilbar sind.
Wenn du z.B. wie bei Status nur fixe Werte hast, dann ist der Ansatz hilfreich.
Wenn du aber z.B. Bereiche durchsuchen musst wie Alt > 18, dann hilft der Ansatz nur bedingt.
Hier könnte man tricksen in dem man ein Dictionary mit dem Alter und der Liste der Personen in diesem Alter führt.
Dann müsste man nur die Keys > 18 suchen und kann alle Treffer in einer Liste liefern.
Bei einigen Tausenden bis Millionen Einträgen dürfte dieser Ansatz besser sein als immer wieder die komplette Liste zu durchsuchen.
Vermutlich gibt es aber auch dafür einen besseren Ansatz.
Sieht aber auch nicht danach aus, dass das Projekt noch großartig aktiv ist.
Letzte Änderung war vor 13 Monaten und es gibt fast 500 offene Issues sowie 47 Pull Requests, wo von einige sogar bis 2018 zurück reichen.
Dabei geht es auch um den Einbau einer Fluent API, was dann auch stark in Richtung EF Core geht.
Dann kann man sich aber die Frage stellen, warum man nicht gleich zu EF Core wechselt.
Die Performance von EF Core war eigentlich bei meinen Tests seit .NET Core 2.x selten ein Problem.
Eher die Clientseitigen Filterungen/Sortierungen etc. die aber weitestgehend auf Serverseite verlagert wurden.
Im Bestfall kannst du ja z.B. mit Entity Framework Core 6+ arbeiten.
Damit brauchst du dann kein SQL mehr sondern arbeitest über Code mit reinen Klassen.
Dürfte noch besser sein als mit ADO .NET alles selbst bauen zu müssen, darum kümmert sich dann Entity Framework unter der Haube.
Klingt fast nach einem Micro OR Mapper ala Dapper.
Weil mit reinen SQLite hast du schon immer mit Connection und Command Objekten in C# gearbeitet.
Dies bildet den Kern der Kommunikation zwischen deiner Software und den Datenbanken wie SQLite.
Du kannst aber gerne mal Beispiele und Informationen zu der "alten" Version liefern.
Dann solltest du dich mit den Admins bei euch mal abstimmen und prüfen ob es dort ggf. in den Logs Meldungen gibt.
Ansonsten bleibt eben auch die Frage wie die Performance der Abfrage auf dem SQL Server aussieht.
Dazu musst du dir entsprechende Ausführungsplane anschauen und gucken wo die Kosten verursacht werden.
Auch ist noch unklar wie die Abfragen aktuell aussehen.
Werde z.b. Updates auch mehrfach auf den gleichen Datensatz ausgeführt weil diese z.B. nicht zusammen gefasst werden?
Es wäre für die DB unnötig wenn du z.B. den gleichen Datensatz mehrfach bearbeitest weil einmal Feld A und einmal Feld B geupdatet werden muss.
Hier dürfte ggf. auch noch Potential für Optimierungen stecken.
Ansonsten müsste auch geprüft werden ob die Latenzen ggf. durch hohe Last auf dem SQL Server zustande kommen.
Wenn hier z.B. primär noch Festplatten zum Einsatz kommen, hat man schon eine Mindestlatenz von einigen Millisekunden.
Je nach Auslastung steigt diese dann auch noch zusätzlich.
Klingt nach der schlechten Kombination von keine Backups sowie fehlenden Rücklagen.
Dadurch stand man schon auf wackligen Beinen, was nun zur Insolvenz der Firma führt.
Sind beides selbstgemachte Problem.
Deshalb sollte man immer bei IT eine Backup Strategie fahren, die einen absoluten Datenverlust weitestgehend ausschließen.
Welche Unterschiede gibt es den zwischen den Api Versionen in der Struktur?
Wenn diese nicht sonderlich groß wären, dann könntest die diese in der gleichen Klasse abdecken.
Falls es z.B. zu Breaking Changes kommt könntest du ggf. mit JToken arbeiten.
Note: This method is only relevant in specific use cases and should only used by advanced programmers
Die Methode manuell aufrufen ist hier vermutlich auch der falsche Weg.
Da du dies in deinen Gettern machst, wird diese auch bei jedem Abrufen der Eigenschaften ausgelöst.
Dadurch tust du dir also keinen Gefallen und verbrennst durch häufige Updates dann zusätzliche Rechenzeit.
Am ende muss ja durch Where die Liste beim Materialisieren z.B. mit ToList() oder mit First/FirstOrDefault() durchlaufen werden.
Das kostet eben Zeit, hast du aber selbst schon bemerkt.
List<T> ist bei großen Listen als Container zum suchen nicht mehr praktikabel, da er alle Elemente durchlaufen muss.
Je nachdem wie man darauf sucht, muss er bei nicht gefundenen Treffern immer durch die ganze Liste laufen.
Wenn du schnell suchen willst und auch fixe Kriterien wie einen eindeutigen Key hast, dann nimm Dictionary und gruppiere damit deine Einträge.
Z.B. könntest du deine Enums als Keys verwenden und die Werte im Value als List<MyPrice> speichern.
Bei Änderungen musst du dann die Listen entsprechend bearbeiten.
Nachtrag:
Bezogen auf Update.
Die Methode wird in deinen Gettern aufgerufen und dann die Listen, Trends etc. geliefert.
Diese Methode sehe ich im Code aber nicht, weiß ich nicht was diese überhaupt macht.
Ansonsten sehe ich nur eine Stelle wo deine Preis Liste gefllt bzw. ein MyPrice Objekt hinzugefügt wird.
Und Slowly scheint Update aufzurufen, was nicht in deinem Code enthalten ist.
Auch ist gefühlt 90% des Code generiert und damit für externe Leute wie mich unbrauchbar.
Das ganze geht offensichtlich in die Richtung von Online Trading und Vergleichen von aktuellen Aktien Kursen, da die Namespaces auf NinjaTrader verweisen.
Vermutlich ist dann dein Ansatz mit dem durchlaufen der Liste schon falsch.
Du machst auch je nach Methode ein Where auf deine Listen.
Daduch kommt es unweigerlich bei großen Listen zu langen Suchzeiten.
Vermutlich wäre teilweise ein Ansatz das ganze mit Dictionary zu lösen.
Kannst du dann aber nur für einen Teil verwenden, sobald due mit Werten größer/kleiner suchen musst, funktioniert der Ansatz nicht mehr.
Ich verstehe immer noch nicht was dein Ziel ist oder sein soll.
Es macht ohne Kontext erstmal keinen Sinn, dass du 4.000 mal durch die Liste laufen musst.
Wenn dann auch noch Berechnungen mit den einzelnen Einträgen dauern können, wirst du um Wartezeiten nicht drum herum kommen.
Man könnte diese zwar noch mit Ansätzen wie Parallel.ForEach auf möglichst alle Kerne verteilen, aber das löst dein Grundproblem nicht.
Alleine mehrfach durch die Listen zu laufen klingt schon nach einem vollig falschen Ansatz.
Im Bestfall macht man es einmal und führt dann alle Operationen in einem Rutsch aus.
Allein dadurch würde man unmengen an unnützen Iterationen und damit Zeit einsparen.
Ebenfalls würde eine Gruppierung der Listen Einträge z.B. mit Dictionary die Suche dann verkürzen.
Aber ohne Kontext kann dir niemand sagen was du hier sinnvoll als Lösung machen kannst.
Bitte liefere Informationen dazu, damit man dies überhaupt mal beurteilen kann wo der Fehler liegt in deinem Konzept liegt.
Der Code an sich gibt eigentlich kein erkennbares Problem wieder.
Auch kann anhand des Snippets kaum ein Performance Problem auftreten.
Das du aber tausendfach durch die Liste läuft richt nach einem falschen Ansatz.
Mir ist auch nicht klar wie ein Performance Problem in deinem C# Code mit SQL gelöst werden sollte.
Ggf. fehlt uns hier Kontext, den du erläutern solltest.
Ansonsten wäre es auch hilreich zu wissen, warum du durch die Listen laufen musst.
Suchst du hier nach Einträgen oder musst du ggf. die Einträge ändern?
Wenn diese z.B. aus einer DB kommen, dann kannst du diese mit einem Update Befehl vermutlich sinnvoller updaten als ales einzuladen durchlaufen und dann zurück zu schreiben.
@ClaraSoft
Da er die Liste rückwärts durchläuft, wäre foreach hier nicht hilfreich.
Generell nimmt sich die for/foreach Schleife nur syntaktisch was.
Unter der Haube machen beide das gleiche.
Der Typ ist gefährlich und wird nicht für die BinaryFormatter Datenverarbeitung empfohlen. Anwendungen sollten so bald wie möglich aufhören, BinaryFormatter zu verwenden, auch wenn Sie der Auffassung sind, dass die verarbeiteten Daten vertrauenswürdig sind.
BinaryFormatter ist unsicher und kann nicht sicher gemacht werden.
Auch zu beim BinaryFormatter zu beachten, dass bei Änderungen an deiner Klasse die bestehenden Dateien nicht mehr deserialisiert werden können.
Du musst dann selbst für Kompatibilität sorgen z.B. duch Versionierung durch Vererbung.
Wenn die Abfrage im Kern immer gleich ist, dann ist es ein enormer Vorteil alles in einer Transaktion zu lösen.
Die Latenzen kommen auch zu einem nicht unbedeutenden Teil daher, dass z.B. die Anfrage erst über das Netz laufen muss und die Antwort wieder zurück.
Ebenfalls dauert auch die Verarbeitung der Anfrage, da diese vom SQL Server geparst und dann verarbeitet wird.
Wenn du auch SqlParameter verwendest, wovon ich erstmal ausgehen würde, dann sollte die Zusammenfassung dem SQL Server die Netzwerk sowie die Zeiten zum parsen der gleichen Abfragen ersparen.
Da du auch schon einen Index nuzt, kann die Ermittlung der passenden Einträge eigentlich auch nicht lange dauern.
Ich vermute, dass allein durch das Kapseln der Abfragen zu einer Transaktion die Zeiten nochmal fallen dürften.
Hat sich bei Massenupdates bei einigen Tausend Datensätzen, die per PK geupdatet wurde, enorm bemerkbar gemacht.
Auc spart man eben viel Ping/Pong zwischen Client und Server aus.
Die Frage wäre auch was bei euch Zeit frisst.
Wenn es quasi das Ping Pong zwischen Client und Server ist, dann kannst du dies durch zusammenfassen in einer Transaktionen verringern.
Wenn die Verarbeitung der Updates selbst die Zeit fisst, müste man eben wissen wie diese ausgeführt werden.
Wenn diese eben keinen Index verwenden, müssen auch große Tabellen seriell gelesen werden.
Das frisst dann nicht nur enorm die Performance sondern kann bei gleichzeiten Zugriffen zu Problemen und Wartzeiten führen.
Mein Gedanke mit dem OR Mapper war eher, dass durch Änderungen an den Objekten der OR Mapper selbst ermittelt welche Felder geupdatet werden müssen.
Dann würde er auch entsprechendes SQL generieren um nur diese Felder zu updaten.
Wenn aber dein SQL durch externe Dateien zusammen gezimmert wird, was mir erstmal nicht ganz geheuer ist, dann funktioniert dieser Ansatz nicht bzw. auch nur mit Aufwand.
Hier müsste man entsprechende Modelle anlegen, die schon dem DB Schema entsprechen.
Aber auch dann bleiben Probleme wie fehlender Index etc. als Performance Bremse vorhanden.
Mir ist aber noch nicht klar wie der Ablauf insgesamt ist.
Wie Abt schon schreibt, muss es ja ein Schema geben, da du nicht SQL mit unbekannten Tabellen/Spalten erstellst.
Dadurch ergibt sich ja schon ein gewisses Schema, die frage wäre nur grob wie dies aussieht.
Oder fahrt ihr hier z.B. eine Art Key/Value Struktur auf einer relationalen Datenbank?
Dafür gibt es dann bessere Ansätze als relationale Datenbanken im NoSQL Bereich.
Kannst du hier ein Sample für die Ini Datei und einer Update Abfrage liefern?
Vielleicht wird dann klarer was das Problem ist und wie man es ggf. anders/sauber löst.
Klingt fast nach dem Lösen eines Problems was z.B. durch OR Mapper bereits gelöst ist.
Wenn du nicht weißt welche Spalten geupdatet werden, dann klingt dies nach dynamischen Updates.
Sowas löst z.B. Entity Framework Core bereits für dich.
Ansonsten müsstest du einfach nur passende Update Anweisungen generieren.
Sind es mehrere, kannst du diese auch einfach in einer Transaktion sammeln und ausführen.
Die Frage ist allerdings was für ein Problem du konkret hast und was du damit lösen willst.
Wenn es ein Performance Problem ist, wie werden dann z.B. die Daten für das Update ermittelt (Where Klausel)?
Ggf. fehlt hier einfach ein Index?
1. Du verwendest .NET 6.0 aber für Json Newtonsoft.Json, warum nicht System.Text.Json?
Gerade bei .NET 5+ sollte man eher auf System.Text.Json setzen falls es keinen Fall gibt, den System.Text.Json nicht abdeckt.
Für einfache De-/Serialisierung sollte es aber passen.
2. In deinen Modeln nutzt du scheinbar JToken für Values.
Hast du hier kein eindeutiges Json bzw. sind die Objekte variabel?
Falls nicht leg dafür eigene Klassen an, die dein Vaue abdecken.
Hier reicht es wenn du das Json aus einer internen Instanz serialisierst.
3. Im DatabaseSettingsService hälst du eine Instanz des AppDbContext Instanz als Member.
Die DbContext instanz sollte nur kurzlebig z.B. innerhalb einer Methode genutzt werden.
Hast du im FileIndexerService besser umgesetzt.
Warum erstellst du den DbContext in der Schleife jedes mal neu?
Leg dir vor deiner File Schleife einen Context an und arbeite darauf.
Ansonsten wäre auch die Frage ob du deine Klasse nicht ggf. immer mit den gleichen Dateien aufrufst.
In dem Fall wäre auch klar warum immer mehr Dateien geändert werden.
Auch solltest du deinen Code überarbeiten.
Deine Methoden beginnen mit _ oder mal mit kleinen Buchstaben.
Die CompareLists Methode liefert Listen im Tuppel Format zurück.
Beides ist nicht wirklich schön zu lesen, letztes solltest du gerade im Sinne von Unit of Work in einem eigenen Objekt kapseln.
@M.L.
Für XNA gibt es MonoGame als Ersatz.
Die bauen auf der API auf, sind aber Platformunabhängig.
Man könnte also auch AntMe mit aktueller .NET Version und MonoGame usmetzen
Ich den Code mal überflogen.
Aktuell ist dieser sehr suboptimal.
Dein Spielfeld ist ein struct mit öffentlichen Membern.
Leg dir eine Klasse an und nutze Eigenschaften (Properties),
Ebenfalls nutzt deine Klasse nur static Methoden, die eigentlich Teil des Spielfeld sein sollten.
Auch ist dein Code zu sehr abhängig von Eingaben/Ausgaben.
Sowas gehört natürlich nicht in Tests.
Deine Spielfeld Klasse muss hier entsprechende Methode anbieten ohne Abhängigkeiten zu Ein-/Ausgaben per Console.