Dataset->Db und nicht immer alle Tabellen speichern

ErfinderDesRades schrieb:

verstehe ich das richtig, dass SqlDependancy eine kontinuirlich geöffnete Connection vorraussetzt?

das wird wohl so sein - wäre sowieso meine nächste Frage gewesen, ob das nicht sinnvoller ist als die ganze zeit die connection zu öffnen und zu schließen?
Je nach Bearbeitungsmodus passiert das ja mehrmals die Minute - eine ständig offne Verbindung fänd' ich jetzt aus rein nützlicher Sicht nicht verkehrt. Hab aber keine Ahnung,
was dahinter steckt (Sicherheit, Last etc.)

Ließe sich aber sicher prüfen, welcher Rechner die Verbindung zur DB aufgebaut hat - sollte die Anwendung mal abschmieren, könnte man die doch beim Neustart der Anwendung schließen und neu öffnen oder?

Zumindest bei Einführung von Ado.Net war das eine wichtige dolle Neuerung, dasses möglich war, dass man Connections nur so lang öffnete, wie der Datenaustausch brauchte.
Eine Dauer-Öffnung galt als ganz schlimm absturz-gefährtet.
Selbst EF handhabt das intern noch immer so, egal, ob da 30 Abfragen in einer Folge kommen: Jede einzelne aufmachen, ausführen, zumachen.

Keine Ahnung, ob das noch technisch sinnvoll ist oder nur eine gute alte Gewohnheit - aber könnte sein.

Ich seh' da sogar Performancesteigerung wenn die Connection dauerhaft steht. Öffnen / Schließen wird ja auch (wenn auch nur ganz gering) Zeit brauchen.
Wäre jetzt nur die Frage, ob man das bei einem Absturz ordentlich gehandled bekommt die wiederherzustellen...

Jo, aber 100 Verbindungen zeitgleich muss man auch erstmal schaffen, wenn's keine öffentliche Anwendung ist. Deine, sowie meine Anwendung
wird ja innerbetrieblich genutzt. Bei uns z.B. können die IT-ler einstellen, was sie wollen

Also hier wird das nachwievor "strongly recommended", Connections immer schnell zu zu machen: docs.microsoft.com/en-us/dotne…oling?redirectedfrom=MSDN
Aber wenn die andererseits SqlDependancy verkaufen - keine Ahnung - vlt. steht das nicht im Widerspruch dazu.

Performance-Unterschiede erwarte ich da nicht. Jedenfalls nicht, wenn die DB Connection-Pooling unterstützt.
Auch nicht, wenn die Abfragen jeweils einigermassen Datenmengen abrufen.
Aber ich bin dem Performance-Argument eh ganz grundsätzlich sehr kritisch gegenüber eingestellt.

Rules Of Optimization

100Volt schrieb:

Der Link ist super!

setzt aber voraus, dass der mysql-server das kann. da wirste mit deinem all-inkl.com nicht weiterkommen. Ich könnte das auf meinem Rootserver noch veranstalten aber den Weg finde
ich zu umständlich. Das muss anders zu lösen sein - die ganzen Unternehmen bekommen das doch auch mit ihrer Software hin

Ich setz die Tage mal ne mini-testanwendung auf mit ner kleinen accessdatenbank hintendran - dann könnte man sich davon mal kopien machen und rumspielen.
Muss ja irgendwie möglich sein.

hihi - ich hab den Link garnet geguckt.
Ich hab ja nur ganz allgemeine Vorbehalte dagegen geäussert, sich von einer dauer-offenen Connection abhängig zu machen.
Weil zumindest früher galt das als höchst problematisch für die Betriebssicherheit.
An anderer Stelle wird auch "strongly recommended", das nicht zu tun.
Und auch neue Entwicklungen - EF - tuns auch nicht.

Ich glaube, dass SqlDependency.Start einen Listener startet, der vom MS-Sql-Server connected wird, sobald etwas in der Dependency Queue steht.
Das benötigt seitens Client keine gesonderte Connection.

Anders könnte es bei "Nachbauten" sein bei DBs, die kein natives SqlDependency unterstützen.
Aber auch da wird es eine Art Listener geben, der die DB dann eben pollt und seine eigene Connection handelt.

Du meinst einen TCPListener oder sowas?

Ich nehme an, es ist ein TCP Listener.
In der Doku ist von einem Listener die Rede.