Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: "Peter Götz" <gssg_nospam@xxxxxxxxxxx>
- Date: Wed, 21 Mar 2007 18:08:44 +0100
Hallo Frank,
Wozu ein serverseitiger Cursor?
Willst Du die Belastbarkeit Deines LANs oder
des Servers testen?
Ich hatte mal gelernt, dass man die Speicherbelastung
auf dem Client-PC durch einen serverseitigen
Keyset-Cursor reduzieren kann, indem also nur die
Keys selektiert werden und der komplette Datensatz
nur dann auf den Client geladen wird, wenn man ihn
braucht. Insbesondere bei Darstellungen im Grid,
wenn gescrollt wird. Außerdem soll so bei einem
einzelnen Datensatz das Updaten auf die Felder
beschränkt werden, in denen sich tatsächlich
etwas geändert hat.
Die Welt hat sich verändert.
Das Problem ist heute nicht mehr beschränkter
Speicherplatz beim Client, Speichergrössen von
1 GB und mehr sind heute meist keine Seltenheit.
Engpass ist vor allem das LAN und der Server selbst.
Die benötigte Datenmenge einmal zum Client laden
und dann in/mit den lokal vorhandenen Daten weiterarbeiten
schont das LAN und den Server. Mehrere Änderungen auf
Clientseite und erst dann in einem einzigen Rutsch diese
Änderungen zur DB zu schicken, erspart viele einzelne
Zugriffe und schont somit wieder LAN und Server.
CursorType = adOpenKeyset zusammen mit clientseitigem
Cursor ist Nonsense und ADO wird daraus ungefragt und
ohne was zu sagen eine sinnvolle Einstellung, nämlich
adOpenStatic machen.
Zum Glück macht ADO daraus automatisch eine
sinnvolle Einstellung,
Darauf solltest Du Dich aber nicht blind verlassen. ADO
versucht, unsinnnige Einstellungen zu korrigieren, es
gibt aber keine Garantie, dass das wirklich in allen
Fällen gelingt. Selber denken ist deshalb schon empfehlenswert.
denn das unterstützt die Idee von OLE DB, dass man
eine Anwendung nur durch Austausch des Providers
(sofort) mit einem anderen Datenbanktyp betreiben
kann.
Das ist eine Behauptung von Werbefritzen, die
aber nicht wirklich nah an der Realität ist.
So macht es schon einen beachtlichen Unterschied,
ob man mit einem SQL-Server oder der Jet-Engine
und einer *.mdb arbeitet. Bei der Jet-Engine wird sich
der Code für die Konfliktbehandlung beim Mehrbenutzerbetrieb
schon beachtlich von Code für einen SQL-Server
unterscheiden müssen.
Mit nur Provider austauschen ist es also keineswegs getan.
Ich kann also z.B. bei adOpenKeyset im Programmcode
bleiben
Nein, das solltest Du nicht tun, da es schlichter Unsinn ist.
ohne Austüfteln zu müssen, dass ich für Datenbank Y
eigentlich adOpenStatic hinschreiben müsste,
weil sie sowieso nur das kann.
Auf die Probleme, die dabei aus dem unterschiedlichen
Verhalten der Datenbanktypen entstehen,
muss man sich allerdings einstellen, wie wahr.
Da hast Du einiges offenbar noch überhaupt nicht verstanden.
Ein ADODB.Recordset verhält sich immer gleich, egal ob
es aus Daten eines SQL-Servers oder einer *.mdb via Jet
mit Daten gefüllt worden ist. Der "Verbraucher" des Recordsets,
also z.B. eines Deiner gebundenen Controls kann nicht erkennen
woher die Daten aus dem Recordset stammen.
Für die Mehrzahl aller Fälle gilt, arbeite mit clientseitigem
Cursor und statischen Recordsets, egal welches Datenbanksystem
dahinter steht.
weil CursorType = adOpenKeySet mit
clientseitigem Cursor technisch nicht möglich ist.
Nach dem was ich über ADO gelesen habe, ist die
CursorLocation adUseServer bei Access sinnlos,
Nicht unbedingt sinnlos, aber eine gewaltige
Ressourcenverschwendung.
Ich kann also, ressourcenverschwendenderweise,
Access mit adUseServer und adOpenKeyset betreiben
Access selbst arbeitet mit den DAO-Methoden
und somit immer mit serverseitigem Cursor.
- und da würde mich mal interessieren,
welche Systemsoftware auf meinem PC dieses
Serververhalten ermöglicht,
Na, die Jet-Engine, die werkelt bei ADO
genauso im Hintergrund wie bei DAO.
Beim Öffnen einer Connection sagst du der Jet-Engine
wo die Datei *.mdb zu finden ist. Der Jet-Engine ist es
dabei egal, ob das ein lokaler Dateipfad oder ein
Netzwerkpfad ist.
Ist es ein lokaler Pfad, dann heisst das für serverseitigen
Cursor, dass eine Bewegung im Recordset eben auch
in der lokal vorhandenen *.mdb stattfindet, ein LAN oder
ein entfernter Dateiserver ist in diesem Fall nicht betroffen.
Ist es dagegen ein Netzwerkpfad muss jede Bewegung
im Recordset auf die entfernte *.mdb zugreifen und
produziert somit eine Menge an Netzwerkverkehr.
Beim clientseitigen Cursor wird einmal das gesamte
Recordset mit allen Daten zum Client geschaufelt und
dann ist erst mal für eine geraume Zeit Ruhe auf dem
LAN und beim Server. Bewegungen innerhalb des
Recordsets interessieren weder das LAN noch den
Dateiserver.
wo doch Access kein Datenbankserver ist,
Access ist ein Programm, mit dem man auf *.mdb
zugreifen kann und das nebenbei noch so Spielchen
wie VBA und die Möglichkeit Reports aus Daten
einer *.mdb zu erstellen bietet.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
.
- References:
- Gebundene Controls aus ADO-Recordset aktualisieren
- From: Frank Lehmann
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: Peter Götz
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: Frank Lehmann
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: Peter Götz
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: Frank Lehmann
- Gebundene Controls aus ADO-Recordset aktualisieren
- Prev by Date: Re: Gebundene Controls aus ADO-Recordset aktualisieren
- Next by Date: Performanceproblem mit SQL Server über VPN
- Previous by thread: Re: Gebundene Controls aus ADO-Recordset aktualisieren
- Next by thread: SQL-Abfrage
- Index(es):
Relevant Pages
|
