TDataSet -> System.Data.DataSet Bridge?

[Bernhard Geyer]

Zitat von tomaten:

Naja viel akzeptieren .NET Klassen als DataSource ja nicht. Bei ADO.NET und connectionless DB wirds mir übel, wenn ich an den Overhead bei ein paar tausend SQL-Abfragen pro Sekunde denke.

Und wieso das? Du holst auch unter ADO.NET jeden Datensatz einzeln. Du verwendest jedoch keine Serverseitigen Curser mehr. Was übrigens auch von der Serverlast her seine Vorteile bietet (vor allem bei MS-SQL-Server, welche für jeden Serverseitigen Curser eine temporäre Tabelle füllen muss, da ja das Multi-Version-Konzept fehlt

Zitat von tomaten:

Vielleicht denke ich auch falsch, aber ich bin froh, dass dbExpress eine ständige Verbindung zur DB hält.

dbExpress ist ein ganz schlechtes Beispiel. Du mußt um die Datenmenge in beiden Richtungen durchlaufen zu können erst die Daten in ein TClientDataset kopieren. Und da bist du eigentlich schon wieder bei disconnected Datasets.

Disconnected heißt primär nicht das du nach jeder Abfrage die DB-Verbindung beendest (wird auch nicht bei ASP.NET gemacht. Da wird sie in den Connection-Pool gelegt), sondern das das Ergebnis deiner Abfrage keine DB-Verbindung mehr benötigt und z.B einfach auf einen anderen Rechner übertragen werden kann (N-Tier-Anwendungen) oder gespeichert werden kann.

Zitat von tomaten:

Ich wollte auch eine Wrapper-Klasse bauen, damit ich nicht jeden .Eof, .Next, FieldByName usw. ersetzen muss, aber es muss doch auch einfacher gehen. Ich kann doch da nicht der Einzige mit diesem Problem sein!?

Vielfach ist es kein großes Problem wenn die DB-Schnittstelle an wenigen Stellen konzentriert ist. So ist bei einem großen Projekt (1 Mio. Codezeilen) die DB-Schnittstelle (mit TDataset-Abhängikeiten) in wenigen 100 Zeilen in einer Unit konzentriert und alles andere läuft mit eigenen (disconnected) Datenklassen. Ein wenige wie ADO.NET, jedoch nicht so flexibel und mächtig.

@Generalissimo: Du hast mich fälschlicherweise zitiert.