Was ich -ehrlich gesagt- nicht recht verstehe, ist das Bestreben, immer alles selbst machen zu wollen. Wenn man aus Lust und Tollerei programmiert, mag das noch einen gewissen Lerneffekt haben, aber wenn ich damit Geld verdienen will oder muss, dann benötige ich doch Jemanden, der mir die Arbeit abnimmt. Zeit ist Geld und eine kurze Überschlagsrechnung kommt zum Ergebnis, das 500 Euro für eine Komponente(nsammlung) lächerlich wenig ist, das es maximal 1-2 Manntagen entspricht.
Wenn ich ein Grid asynchron befüllen muss, weil es einfach zu viele Daten sind, dann habe ich einen Fehler im Programmdesign bzw. der
GUI. Es gibt keinen einzigen Fall, in dem der Anwender mehr als -sagen wir- 1000 Datensätze wirklich benötigt. Wozu also einen Kopf um asynchrone Datenübertragung machen? Wenn der Anwender aber das nunmal partout so will, dann bekommt man das auch ohne serverseitigen Cursor hin, ein PK reicht allemal (und etwas 'Clustered Index' Äquivalentes).
Wenn(!) Du aber partout 100.000 Records anzeigen willst, ohne fetch-On-demand, dann versuch es mal (ieh! Fremdkomponente!) der VirtualTreeview von Mike Lischke. Ich glaube, die kann Daten auch in einem Gitter anzeigen. Aber wenn Du alles selbst basteln willst, dann nimm ein TDrawGrid / TStringGrid, ne TScrollBar und ein bisserl Gehirnschmalz. Aber wie gesagt, das ist der Versuch, Amateur-
Access-Romantik mit einem
SQL-Server zu fahren. Du haust Dir massig Load auf den Server, nur damit ein Anwender mal durchscrollen kann. Machen das 100 Anwender, benötigst Du sofort einen zweiten (oder dritten) Server.
Eine
DB-Brücke ist schon was Feines, aber da greif ich doch einfach zu vorgefertigten Komponenten (Zeiteffizienz) z.B. DataAbstract von RemObjects. Es ist mir sowas von egal, ob die EXE nun 1 oder 10 MB groß ist. Weiterhin ist es i.A. irrelevant, ob eine
DB-Abfrage nun in 10ms oder 30ms abgearbeitet ist, denn die Performancebremse #1 sitzt i.A. eh vor dem PC. Einerseits der Programmierer mit falschen Ansätzen und Algorithmen, und dann der Anwender mit dem stetigen Bestreben, etwas anderes zu tun, wie Kaffeetrinken, Zeitung lesen etc.
Das einzige Argument für das 'Selbermachen' wäre die Vermeidung von echten Programmfehlern. Wer sich z.B. bei
ADO mal die
SQL-Kommandos angeschaut hat, die generiert werden, wird sich nach kurzer Analyse entweder nach Alternativen umschauen oder sofort anfangen, soetwas selbst zu bauen. Insofern kann ich die Implementierung einer
DB-Bridge nachvollziehen.
Last, but not least ein Wort zu Drittanbietern: Ich habe es aufgegeben, irgendwelche Freeware- oder Frickelkomponenten zu installieren, denn da ist es wirklich so, das dem Autor i.A. nach einigen Jahren die Luft ausgeht. Daher besorgt man sich nach reiflicher Überlegung ganz bestimmte Komponenten bei großen Anbietern (inkl. Sorucecode) und kann sicher sein, über die nächsten Jahre begleitet zu werden.
Im Gegenzug bekommt man unglaublich mächtige Komponenten, die dann auch mal dafür sorgen, einen zusätzlichen Auftrag zu bekommen. Ich hatte mir vor ca. 6 Jahrne(?) die DevExpress-Teile zugelegt und einen Prototypen zusammengeklickt: Der Auftrag wurde erteilt und ich hatte das Geld nach 2 Wochen 10x wieder drin.
Ich investiere lieber eine Woche mit einer Recherche über bereits fertige Lösungen, anstatt mich hinzusetzen, um sowas selbst zu basteln.