ADO (MS-SQL) + clUseServer + DBGrid-Anbindung

[Bernhard Geyer]

Ich habe meine Anwendung für den Zugriff auf MS-SQL-Datenbanken auf ADO (Express) umgestellt.

Jedoch ist mir folgendes Performance-Grab aufgefallen:
Öffne ich nun mit obigen Einstellungen (clUseServer + ctKeySet) eine große Tabelle mittels SELECT * FROM <MeineTabelle>, so dauert es relativ lange (mehrere Sekunden). Die gleiche Abfrage über einen BDE + ODBC-Eintrag ergibt keine Verzögerung beim Öffnen der Query-Komponente.

Alle anderen Einstellungen von CuserType (außer ctKeySet) sind nicht für eine Bindung an ein DB-Grid geeignet (Fehlermeldung, das Datenmenge keine Positionsmarken unterstützt).

Irgendeine Idee welche Einstellungen performancemäßig gut sind und an ein DB-Grid gebunden werden können.

[trifid]

Hallo Bernhard,

Zitat:

Öffne ich nun mit obigen Einstellungen (clUseServer + ctKeySet) eine große Tabelle mittels SELECT * FROM <MeineTabelle>, so dauert es relativ lange (mehrere Sekunden). Die gleiche Abfrage über einen BDE + ODBC-Eintrag ergibt keine Verzögerung beim Öffnen der Query-Komponente.

Warum verwendest Du clUseServer ?
a) ab .net wird diese Art von Cursor nicht mehr unterstützt
b) die Daten müssen früher oder später auf den Client übertragen,
was spricht gegen ein clUseClient
c) Andreas Kosch - Standardregel
verwende bei MS Access clUseServer
MS SQL clUseClient

Zitat:

Alle anderen Einstellungen von CuserType (außer ctKeySet) sind nicht für eine Bindung an ein DB-Grid geeignet (Fehlermeldung, das Datenmenge keine Positionsmarken unterstützt).

Warum willst du in einem Grid Daten editieren ?
Macht meistens Schwierigkeiten

Ausserdem ist es nicht gut eine grosse Tabelle in ein DataSet reinzuziehen (eben wegen Performence, etc)
dafür gibt es eine WHERE-Clausel

Oder Teile die Maske auf
oben Grid zum browsen
unten Eingabe oder Änderungen

[Bernhard Geyer]

Zitat:

Warum verwendest Du clUseServer ?
a) ab .net wird diese Art von Cursor nicht mehr unterstützt
b) die Daten müssen früher oder später auf den Client übertragen,
was spricht gegen ein clUseClient
c) Andreas Kosch - Standardregel
verwende bei MS Access clUseServer
MS SQL clUseClient

zu a, Das Programm ist und wird auch in nächster Zukunft nur für Win32 angeboten werden. Für eine Portierung auf .NET ist es sehr aufwendig und bringt auch keine großen Vorteile (außer das man sagen kann das es eine .NET-Anwendung ist)

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.

zu c, Und wieso konnte man mit BDE Herrlich ohne große Performanceeinbußen Serverseitige Curser + Grid verwenden? Alles wird doch nicht immer besser

Zitat:

Warum willst du in einem Grid Daten editieren ?
Macht meistens Schwierigkeiten

Hab ich was von Editieren geschrieben? 8)
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.

[quote]Ausserdem ist es nicht gut eine grosse Tabelle in ein DataSet reinzuziehen (eben wegen Performence, etc)
dafür gibt es eine WHERE-Clausel[quote]
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.

[trifid]

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

[shmia]

Zitat von Bernhard Geyer:

Alle anderen Einstellungen von CuserType (außer ctKeySet) sind nicht für eine Bindung an ein DB-Grid geeignet (Fehlermeldung, das Datenmenge keine Positionsmarken unterstützt).

Ohne Primary Key auf jeder Tabelle geht gar nichts.
Goldene Regel für alle Datenbanken: nur Tabellen mit Primary Key können problemlos in einem DBGrid angezeigt werden.

Folgender View für den MS SQL Server zeigt dir alle Tabellen ohne PK an:

SQL-Code:

CREATE VIEW dbo.ViewNoPrimaryKeys
AS
SELECT name
FROM sysobjects
WHERE id NOT IN
        (SELECT b.id
      FROM sysconstraints b, sysobjects c
      WHERE c.type = 'K' AND c.id = b.constid) AND type = 'U'

Mit PK gibt es keine Probleme mit clientside Cursor.

[Robert_G]

@trifid

Ich verwende generell serverseitige unidirektionale Cursor WANN IMMER ES GEHT!
Weißt du auch warum? Es ist so ziemlich die schnellste Art Daten von einem DB-Server abzufragen.
Die Zwischenschicht eines Client cursors klaut dir mindestens die Hälfte des möglichen Datendurchsatzes.

Zitat von trfid:

a) ab .net wird diese Art von Cursor nicht mehr unterstützt

Das ist absolut falsch! Ich benutze auch unter .Net REF Cursor (eine Referenz auf einen Cursor, der auf dem Server geöffnet wurde).

Eine Suche nach "REF CUrsor" in der SDK Doku ergibt (Ranking 3):

Zitat von .Net SDK Doku:

The following C# example assumes that you have created this stored procedure.

SQL-Code:

create or replace package sp_pkg as
      type refCursorxx is ref cursor;
procedure getdata(a1 out refCursorxx, a2 out refCursorxx);
end;
create or replace package body sp_pkg as
       procedure getdata(a1 in number, a2 out refCursorxx) is
       begin
            open a1 for select * from emp;
            open a2 for select * from dept;
            end getdata;
       end;

The following C# example demonstrates how you might obtain table and column information using the stored procedure.
[C#]

Delphi-Quellcode:

OracleConnection conn = new OracleConnection("Data Source=Oracle8i;Integrated Security=yes");
Conn.Open;
OracleCommand cmd = conn.CreateCommand();
cmd.CommandText = "sp_pkg.getdata";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(new OracleParameter("a1", OracleType.Cursor)).Direction = ParameterDirection.Output;
cmd.Parameters.Add(new OracleParameter("a2", OracleType.Cursor)).Direction = ParameterDirection.Output;
DataSet ds = new DataSet();
OracleDataAdapter adapter = new OracleDataAdapter(cmd);
adapter.Fill(ds);

[Bernhard Geyer]

Zitat von trifid:

a) Du hast aber SELECT * FROM <MeineTabelle>
b) und für eine Bindung an ein DB-Grid geeignet
geschrieben
jetzt doch nicht

Doch schon. Jedoch werden bei einem vernünftigen DB-Grid und serverseitigen Curser nur soviel Daten zum Client übertragen, wie die Scrollposition im Grid ist.

Zitat von trifid:

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.

Wir haben auch die BDE aus unserem Produkt (fast) eliminiert. Jedoch ist es für mich nicht einsichtig, wieso M$ hier nicht auch diesen Fall vorgesehen hat.

Zitat von trifidaber:

dennoch Wartezeiten ?

Nur beim Grid wenn dieser Curser-Komponation verwendet wird. Alles andere Geht sehr schnell

Zitat von trifidaber:

hast du dir mal Gedanken gemacht wie lange ein Anwender braucht um 50000 Datensätze anzuschauen?

Manchmal ist es jedoch einfach über eine größer Datenmenge per Scrollbar drüberzuschauen als Tausend Where-Bedingungen auszuprobieren.

Zitat von trifidaber:

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

zu a, Da bin ich mittlerweile auch angekommen. Ich versuch mal einem normales Grid + Forward-Curser + eigenes Caching-Mechanismus zu einem vernünftigen Ergebniss zu kommen.

Zitat von shmia:

Ohne Primary Key auf jeder Tabelle geht gar nichts.
Goldene Regel für alle Datenbanken: nur Tabellen mit Primary Key können problemlos in einem DBGrid angezeigt werden.

Die Tabelle hat Primärschlüssel. Das Problem liegt an ADO.
Bei der BDE/ODBC-Kombination wird einfach ein "select * from MyTable" abgeschickt und über fetching werden nur die benötigten Daten abgerufen.
Bei ADO wird mittles "exec sp_cursoropen @P1 output, N'select * from mat', @P2 output, @P3 output, @P4 output ..." ein Curser auf Server-Seite angelegt. Und wenn die Tabelle sehr groß ist, dauert das.
Mir wäre ja geholfen, wenn ich ADO dahingehend bekomme, das Bookmarks (für Grid nötig) unterstützt werden, die Daten wenn möglich auf den Server bleiben und nicht per "exec sp_curseropen..." gearbeitet wird, sondern wie bei BDE/ODBC nur einfach die Query abgeschickt würde.

[trifid]

@Robert_G

Zitat:

Das ist absolut falsch! Ich benutze auch unter .Net REF Cursor (eine Referenz auf einen Cursor, der auf dem Server geöffnet wurde).

OK, schon wieder falsch ausgedrückt
a) es geht hier um Probleme mit MS-SQL-Server
die Version kann hier 6.5, 7.0 oder 2000 sein oder die MSDE
b) als ich von .NET sprach meinte ich ADO.Net
c) habe ich etwas falsches gelesen
im Buch A.Kosch Crashkurs .net für Delphianer Seite 275 Kapitel 6.3.3
"Keine serverseitige Cursor"
d) sicherlich kann ein Cursor serverbasierender sein, wenn dieser auf den
SQL-Server mittels in einer StoredProcedure ausgeführt wird
das hat aber nichts mehr mit ADO zu tun


@Bernhard

Zitat:

Jedoch werden bei einem vernünftigen DB-Grid und serverseitigen Curser nur soviel Daten zum Client übertragen, wie die Scrollposition im Grid ist.

beim clientseitigen Cursur wird alles auf einen Schlag im Arbeitsspeicher geladen
OK, das ist eine lange Wartezeit
Aber selbst wenn du nur 50000 Datensätze hast und 20Stück angezeigt werden sind das immer noch 2500x nachladen
Dieses nachladen dauert länger insgesamt (auf die 2500x gesehen) länger wie auf einmal

Zitat:

Nur beim Grid wenn dieser Curser-Komponation verwendet wird. Alles andere Geht sehr schnell

das ungewisse dabei ist dass wir Entwickler nicht wissen was der Anwender macht
Sicherlich mit einen Cursor mit dem man nur vorwärtsblättern kann geht alles schneller,
aber macht das auch der Anwender?, meistens will er wieder zurück scrollen um sich einfach zu
vergewissern

Zitat:

Manchmal ist es jedoch einfach über eine größer Datenmenge per Scrollbar drüberzuschauen als Tausend Where-Bedingungen auszuprobieren

aber wenn ich nun sehe dass etliche WHERE-Bedingungen berücksichtigt werden müssten, dann huscht doch
der Anwender ziemlich flux über die Datensätze und sucht nach Muster - und diese
lassen sich halt nur mit WHERE's beschreiben
Wenn der Anwender Zeit hat über 50000 Datensätze auf einmal zu gehen, dann hat er auch Zeit
sich vorher Gedanken zu machen, nach was er überhaupt sucht!
Meistens und leider sieht das der Anwender etwas anders

Zitat:

Bei ADO wird mittles "exec sp_cursoropen ...

a) habe noch nicht ausprobiert und somit keine Erfahrung
b) in einer StoredProc "DECLARE cursor_name CURSOR GLOBAL" ... wichtig GLOBAL oder Doku mal anschauen DECLARE CURSOR
mit Hilfe einer zweiten StoredProc die Daten fetchten,
aber dann brauchst wahrscheinlich ein eigens dafür programmiertes Grid, welches das alles verwaltet
bin mir aber nicht sicher ob das wirklich funktioniert

Nochmals zu den SELECT * FROM Mat
a) braucht der Anwender alle * Felder
b) machmal ist ein ORDER BY eine grosse Hilfe für den Anwender
c) besteht der PrimaryKey aus einen oder aus mehrere Feldern
d) sicherlich hat die Tabelle noch SecundaryKey's, oder
e) klingt komisch, aber hast du es mal über einen View probiert
f) wird der Standard-Borland-DBGrid verwendet oder Third-Party

schon mal mit dem TBetterADODataSet
http://www.entwickler-forum.de/webx?...sD.1@.4a8702c3
probiert ?

[Bernhard Geyer]

Zitat von trifid:

beim clientseitigen Cursur wird alles auf einen Schlag im Arbeitsspeicher geladen
OK, das ist eine lange Wartezeit
Aber selbst wenn du nur 50000 Datensätze hast und 20Stück angezeigt werden sind das immer noch 2500x nachladen
Dieses nachladen dauert länger insgesamt (auf die 2500x gesehen) länger wie auf einmal

Das wäre für diesen Dialog/Teildialog egal. Es ist halt schlecht wenn erst mal 10-20 sec gar nichts passiert.

Zitat von trifid:

Sicherlich mit einen Cursor mit dem man nur vorwärtsblättern kann geht alles schneller,
aber macht das auch der Anwender?, meistens will er wieder zurück scrollen um sich einfach zu
vergewissern

Dazu habe ich mir schon überlegt einen Forward-Curser zu verwenden, die Daten in einem eigene Speicherobjekt zu kopieren und mit einem Grid im Virtual-Modus anzuzeigen. Je nachdem wieweit der User gescrollt hat, wurde auch der Forward-Curser gescrollt. Zurück geht auch, da ja alles in einem eigenen Speicherobjekt gecached ist.

Zitat von trifid:

Meistens und leider sieht das der Anwender etwas anders

Da hast Du vollkommen recht. Als Entwickler hat man immer andere Ansichten als der User

Zitat von trifid:

a) habe noch nicht ausprobiert und somit keine Erfahrung
b) in einer StoredProc "DECLARE cursor_name CURSOR GLOBAL" ... wichtig GLOBAL oder Doku mal anschauen DECLARE CURSOR
mit Hilfe einer zweiten StoredProc die Daten fetchten,
aber dann brauchst wahrscheinlich ein eigens dafür programmiertes Grid, welches das alles verwaltet
bin mir aber nicht sicher ob das wirklich funktioniert

Eine spezialprogrammierung Grid + ADO ist nicht möglich, da ich auch nocht MySQL und Oracle unterstützen muß. Und da gehen wir native drauf (mysqllib.dll bzw. .NET8-Client)

Zitat von trifid:

Nochmals zu den SELECT * FROM Mat

Dieses Beispiel ist eine Vereinfachung. Der User kann bestimmen welche Spalten er sehen will (und die Query wird entsprechend optimiert

Zitat von trifid:

schon mal mit dem TBetterADODataSet

Wird vermutlich nichts bringen, da es ja auch auf ADO aufsetzt und das Problem nicht ADOExpress/dbGo ist sondern ADO in seiner eigentlichen Form.

Ich werde noch 2 Möglichkeiten Ausprobieren:
a, Verwendung von Forward-Curser + Eigenes-Caching und nicht DB-Gebundenes Grid
b, Verwendung von Select TOP xyz .... order by "Primärschlüsselfelder" um definitiv nur maximal xyz-Datensätze anzuzeigen und für weitere Datensätze wird eine neue Query abgesendet, welche die Datensätze nach den schon vorhandenen liefert (ähnlich wie es ja auch im Internet bei Suchmachinen üblich ist

Danke für alle Tips/Hinweise