Eines der zentralen Punkte ist es dabei, ob du mit Datatsource/Dataset arbeitest (so wie das ca. 95% aller Delphianer machen) oder die gerade gebrauchten Daten in eigenen Strukturen/Objekten/Listen im Client speicherst (so wie unter anderem wir das mittlerweile nur noch machen). Das zweite Verfahren ist bei uns sogar immun gegen das Umschalten auf einen zweiten replizierten Server, falls der erste nicht mehr erreichbar ist. Bei Datasource/Dataset musst du ziemlich viel wieder herstellen, damit der Anwender wieder annähernd das gleiche sieht wie vorher. Die DS/DS Komponenten verlieren beim Verbindungsabbruch nämlich so ziemlich alles, was die brauchen, um wieder sinnvoll als zu arbeiten (TField Objekte, Transaction bzw.
Query Handles, Bookmarks bzw Cursorposition, etc).
Einige Komponenten für Datasource/Dataset Operationen können das zwar relativ gut vereinfachen, aber perfekt hat das aus meiner Sicht keine einzige gelöst, daher auch der komplette Umstieg weg davon bei uns. Wenn ich was von der Datenbank will, sag ich der das, wenn die dann nicht antwortet, reagier ist eben so wie ich will (u.a. umschalten auf anderen Server, lokale Storage oder was auch immer). Aber nur weil irgendjemand bei mir im Front End durch eine Datenmenge scrollt, werden noch lange keine weiteren Datensätze gefetcht. Und ganz nebenbei geschieht auch nahezu alles in extrem kurzlebigen Transaktionen.
Das löst zwar ggf. deine Probleme auf Basis Datasource/Dataset nicht, sofern du das benutzt, aber es geht ja auch in deiner Frage um Prinzip Fragen.