Re: Cursor ODBC
From: Heinz Jacobs (HJacobs_at_eat-engineer.de)
Date: 10/07/04
- Next message: Elmar Boye: "Re: Cursor ODBC"
- Previous message: Elmar Boye: "Re: @Elmar"
- In reply to: Elmar Boye: "Re: Cursor ODBC"
- Next in thread: Elmar Boye: "Re: Cursor ODBC"
- Reply: Elmar Boye: "Re: Cursor ODBC"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 7 Oct 2004 09:55:31 +0200
"Elmar Boye" <ElmarB@gmx.net> schrieb im Newsbeitrag
news:2sii4mF1ld5p2U1@uni-berlin.de...
> Hallo Heinz,
>
> Heinz Jacobs <HJacobs@eat-engineer.de> schrieb ...
> > Hallo Experten,
> > ich habe ein etwas schwierig zu formulierendes Thema.
> > Umgebung: W2K SP4, A2K, MSDE von Office 2000, Kopplung über ODBC.
> >
> > In meinem Buch über Access steht folgendes:
> > Zitat:"Ein dynamischer Cursor bietet die größte Funktionalität, aber
> > die niedrigste Leistung. Der Datensatzgruppe stehen nicht nur die
> > Änderungen zur Verfügung, die andere Benutzer an den Daten
> > vorgenommen, sondern auch hinzugefügte Datensätze und Löschungen."
>
> wohl aus einer MS Dokumentation abgeschrieben...
Nein, das hat dann die Buchautorin getan......
>
> >
> > Nun zu meinen Fragen:
> > 1.) Das heißt also, das sich die Anzahl der Datensätze des Recordsets
> > während meiner Programmbearbeitung ändern kann?
>
> Ja. Aus der SQL Server Dokumentation zu DECLARE CURSOR
> <Zitat>
> DYNAMIC
>
> Definiert einen Cursor, der alle in den Zeilen vorgenommen Datenänderungen
> in seinem Resultset widerspiegelt, wenn Sie im Cursor scrollen.
> Datenwerte, Reihenfolge und Mitgliedschaft der Zeilen können sich bei
jeder
> Abrufoperation ändern. Die Abrufoption ABSOLUTE wird für dynamische
> Cursor nicht unterstützt.
> </Zitat>
>
> Und das spiegelt sich weitgehend auch bei einem ADO oder ODBC
> serverseitigem Cursor wieder. Absolut wäre hier z. B. ein
> Move mit Zeilenangabe.
>
> > Wenn das so ist, wo werden die neuen Datensätze eingefügt, am Ende
> > oder dort wo sie laut Primärschlüssel hingehören?
>
> Eine vorgegebene Sortierung gibts in SQL nicht, und so gilt:
> Dort wo wie laut zugrundeliegender Abfrage stehen müssten, also
> wie es durch ORDER BY bestimmt wird.
> Gibts Du kein ORDER BY an, so kommen die Daten wahrscheinlich in der
> Reihenfolge eines Clustered Index, sicher ist das aber nicht.
> Denn intern wird jedes Mal ein Positionierungsvorgang vorgenommen,
> und da wählt der SQL Server ohne Restriktionen den ressourcenschonendsten
> Weg. Wobei dynamische Cursor eben durch die erforderlichen
> Positioniervorgänge nicht gerade effektiv sind.
>
> > 2.) Wenn Datenänderungen vorgenommen werden, stehen sie auch in meinem
> > Recordset. Wer ist die treibende Kraft für die Aktualisierung des
> > Recordsets. Schickt der Server die Daten bei Änderungen oder fragt der
> > Client regelmäßig nach?
>
> Neue Daten siehst Du erst mit dem nächsten Move. Und es kann z. B.
> passieren das ein Vor- und Zurückblättern via
> rst.MoveNext
> rst.MovePrevious
> dir nicht etwa den gleiche Zeile sondern eine andere liefert, weil
> eine Zeile gelöscht, eingefügt oder verschoben wurde. Und weil
> das so ist, gibts auch keine absoluten Positioniervorgänge.
>
> > Nach meinem Verständnis muss der Server bei der Kopplung über ODBC
> > die ganze Tabelle schicken. Stimmt das?
>
> Nein. Vielmehr wird jeweils nur die jeweilige Zeile geliefert und
> intern im SQL Server vermerkt wo sich der Cursor gerade befindet.
> Allerdings muss auf der anderen Seite jedes Mal in der Tabelle
> nach der nächsten, vorigen usw. Zeile gesucht werden. Was eben
> das Aufwändige ist - wie oben schon erläutert.
>
> Und sollte man eher einen Keyset Cursor verwenden (DAO: adOpenDynaset),
> dort ist die Mitgliedschaft festgelegt, was zwar auch Ressourcen
> belegt, aber die späteren Zugriffe sind wesentlich performanter.
>
> Einen dynamischen Cursor kriegst Du ohnehin nur mit OdbcDirect (RDO)
> oder ADO und serverseitigen Cursor.
> Und auch nur dort wo dieser überhaupt umgesetzt werden kann -
> nicht möglich Abfragen, die nicht nicht genau auf eine Zeile zeigen
> (wie DISTINCT, GROUP BY). Dort wird eine Umwandlung in einen
> Keyset oder Static Cursor vorgenommen.
>
>
> > 3.) Ich habe ein BSP-Prg, wo ein Recordset in einem Modul geöffnet
> > wird und beim Verlassen nicht geschlossen wird. Sind an der Stelle
> > Probleme zu erwarten?
>
> Ja, solange dieses Recordset nicht geschlossen wird, bleiben die
> Ressourcen und vor allem auch Sperren bestehen. Was bedeuten kann,
> dass ein anderer auf die Daten nicht zugreifen oder sie ändern kann.
> Also tunlichst ändern.
>
> Gruss
> Elmar
>
Hallo Elmar,
vielen Dank für die wirklich sehr gute, ausführliche und schnelle Antwort.
Verstehe ich es richtig, wenn man sagt, dass für jeden VBA Recordset der
Server die Position des Recordset "speichert" ? Das hätte ja zur Folge, dass
es irgendwann zu einem Fehlverhalten des Servers kommen muss.
Wenn der Server die Positionen speichert, taucht die Frage auf, wann löscht
er diese. Beim Abmelden des Clients, beim Neustart des Servers ?
Gruß
Heinz
- Next message: Elmar Boye: "Re: Cursor ODBC"
- Previous message: Elmar Boye: "Re: @Elmar"
- In reply to: Elmar Boye: "Re: Cursor ODBC"
- Next in thread: Elmar Boye: "Re: Cursor ODBC"
- Reply: Elmar Boye: "Re: Cursor ODBC"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
