Hallo,
Zitat:
zu a
war nur als Info für die Zukunft
Zitat:
zu b, nicht unbedingt alle Daten. Nur soweit er Scrollen will (und muß). Wenn ich alle Daten am Client benötige (und nicht unbedingt ein Grid zu komplettanzeige benötige), so wird teilweise über einen Forward-Only-Curser/Client-Curser gearbeitet.
a) Du hast aber
SELECT * FROM <MeineTabelle>
b) und
für eine Bindung an ein DB-Grid geeignet
geschrieben
jetzt doch nicht
Zitat:
zu c, Und wieso konnte man mit
BDE Herrlich ohne große Performanceeinbußen Serverseitige Curser + Grid verwenden? Alles wird doch nicht immer besser
weil die
BDE ein anderes Design hat wie
OLE-
DB und
ADO 
Ich möchte nicht mehr mit der
BDE auf meinen
SQL-Server zugreifen. Da ist mir
ADO mit all seinen Bugs lieber.
Zitat:
Hab ich was von Editieren geschrieben?
nö
Zitat:
Das Grid ist nur für die Anzeige und Selektion/Mehrfachselektion da. Alles andere wird mit optimierten
SQL-Anweisungen durchgeführt. Deshalb auch keine Schwierigkeiten zu erwarten.
aber dennoch Wartezeiten ?
Zitat:
Nur bei
ADO (und bei
MySQL weil es dort keine Serverseitigen Curser gibt. Orale und ADS im Lokalbetieb funktionieren Problemlos. Die Where-Bedingung (welche auch verwendet wird) verringert zwar die Datenmenge, jedoch spech ich hier von bis zu 10.000.000 Mio. Datensätzen. Und wenn die Where-Anweisung immer noch 50.000 Datensätze übrig läßt...
Und für andere "richtige"
SQL-Datenbanken (Oracle) stellt das ja auch kein Problem da.
a) bei 10.000.000 Mio. Datensätzen ist es vorerst egal was man macht, wichtig ist dass man
eine
WHERE-Klausel hat
50.000 Datensätze übrig läßt... in einem Grid
hast du dir mal Gedanken gemacht wie lange ein Anwender braucht um 50000 Datensätze anzuschauen ?
b) es gibt sicherlich Strategien wo ein serverseitiger Cursor einen clientseitigen vorzuziehen
ist, aber wegen deiner
Selektion/Mehrfachselektion würde ich mir ein anderes
"Filter"-Konzept überlegen.
c) den ADS mit einen klassischen
SQL-Server vergleichen, ist bei der Menge an Daten vielleicht
realisierbar aber fragwürdig