Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: "Peter Götz" <gssg_nospam@xxxxxxxxxxx>
- Date: Wed, 21 Mar 2007 12:28:33 +0100
Hallo Frank,
vielen Dank für Dein Beispielprogramm. Ich habe es
ausprobiert, und da alles wie von Dir beschrieben
funktioniert, habe ich mich gefragt, warum in meinem
Programm die Änderungen am Recordset nicht
automatisch in den Controls erscheinen.
Da ich Deinen Code nicht kenne, weiss ich
darauf auch keine Antwort.
Meine Anwendung muss nach Vorgabe des
Auftraggebers so funktionieren, dass problemlos
zwischen einer Access 2002- oder Oracle-DB
umgeschaltet werden kann.
Na ja, das "problemlos" würde ich mal in
Anführungszeichen setzen.
Es handelt sich immerhin um zwei völlig verschiedene
DB-Zugriffstechniken.
Eine *.mdb ist eine simple Datei auf die mit der
Jet-Engine, welche beim Client läuft zugegriffen wird.
Es gibt also keinen Server, der Zugriffskonflikte beim
Mehrbenutzerbetrieb erkennt und koordiniert. Das ist im
Fall *.mdb/Jet-Engine Aufgabe Deines eigenen Programmcodes.
ORACLE und/oder SQLserver sind aktive Serverprogramme,
die in der Lage sind, solche Mehrbenutzerkonflikte selbst zu
erkennen und (in Grenzen) zu koordinieren.
Das Nichtfunktionieren hat mit der Cursor-Location zu tun.
Die Änderungen am Recordset erscheinen nur dann
automatisch in den Controls, wenn die Cursor-Location
bei Access adUseClient ist
Es gibt eigentlich keinen ernsthaften Grund, nicht mit
CursorLocation = adUseClient zu arbeiten.
und bei SQL-Server (momentan als Ersatz für Oracle-DB,
da keine Oracle-DB zur Hand) adUseServer.
Wozu ein serverseitiger Cursor?
Willst Du die Belastbarkeit Deines LANs oder des Servers testen?
Der zugrunde liegende Recordset wird bei beiden
DB-Typen mit CursorType adOpenKeyset
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.
und LockType adLockOptimistic geöffnet.
Der Provider für Access ist OLE DB Jet 4.0, die
MDB-Version momentan noch Access 97.
Nach dem Öffnen des Recordsets wird bei Access
der tatsächlich eingenommene CursorType adOpenStatic.
s.oben:
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.
da es keine Datenbank-Engine auf einer (nicht
vorhandenen) Server-Seite gibt.
Verwirrend sind dabei für mich allerdings 2 Punkte:
1. Wenn man die Access-DB mit adUseServer
öffnet und einen Recordset mit adOpenKeyset
öffnet, dann ist der tatsächlich eingenommene
CursorType adOpenKeyset.
Wer organisiert dieses Verhalten, wo es doch
keinen Access-Server gibt?
Clientseitiger Cursor bedeutet, dass die gesamten
Daten Deines Recordsets lokal im Speicher des
Clients liegen. Die DB selbst erfährt erst mal gar nichts
davon, wenn Du in Deinem Recordset zu einem anderen
Datensatz wechselst oder irgendwelche Änderungen am
RS vornimmst. Die Daten in Deinem RS sind völlig
unabhängig von der DB aus der sie ursprünglich
stammen. Zwischen RS und der DB gibt es keine
permanente Verbindung. Ein dynamischer Cursor bzw.
ein diesem ähnlicher CursorTyp adOpenKeyset ist
deshalb rein technisch gar nicht möglich. ADO
erkennt das und korrigiert Deine unbrauchbare
Einstellung selbsttätig.
2. Wenn man die Access-DB mit adUseClient öffnet
und einen Recordset mit adOpenKeyset
öffnet, dann ist der tatsächlich eingenommene
CursorType adOpenStatic.
Weil nur das eine zu CursorLocation = adUseClient
passende Einstellung ist.
Mit dieser Konstellation erscheinen wie gewünscht
die Änderungen am Recordset automatisch in den
Controls. Und dieser Recordset scheint voll für Insert,
Update, Delete geeignet zu sein.
Ja, warum sollte es nicht so sein?
Allerdings lese ich immer wieder, das ein Static
Cursor read-only ist.
Es wird viel geschrieben, leider offenbar auch solcher Unsinn.
Warum kann man dann damit eine Access-MDB updaten???
Weshalb sollte ein mit CursorLocation = adUseClient und
CursorType = adOpenStatic denn "readonly" sein? Natürlich
kann man ein solches Recordset ändern und die vorgenommenen
Änderungen auch in die zugrundeliegende DB übertragen. Egal
ob es sich dabei um eine *.mdb oder eine DB auf einem SQL-
Server handelt.
Wenn Du Dein RS mit LockType = adLockOptimistic geöffnet
hast, dann kannst Du Datensätze dem RS hinzufügen, Ändern
oder Löschen und mit nachfolgendem RS.Update die Änderung
ins RS übernehmen und auch gleich zur DB übertragen.
Bei einem RS mit LockType = adLockBatchOptimistic bewirkt
ein RS.Update lediglich die Übername von Änderungen, neuen
Datensätzen und Löschungen in das lokale Recordset. Erst ein
RS.UpdateBatch überträgt dann alle seit dem letzen
RS.UpdateBatch am RS vorgenommenen Änderungen zur DB.
Man kann bei dieser Arbeitsweise also mehrere Änderungen am
RS vornehmen, diese nötigenfalls auch noch überprüfen, korrigieren
und evtl. auch wieder zurücknehmen und erst wenn allse für gut
befunden ist, werden alle Änderungen in einem Rutsch per
RS.Update zur DB übertragen. Das erspart viele einzelne
DB-Zugriffe und kann so das LAN und auch den Server deutlich
entlasten.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
.
- Follow-Ups:
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- From: Frank Lehmann
- Re: Gebundene Controls aus ADO-Recordset aktualisieren
- 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
- Gebundene Controls aus ADO-Recordset aktualisieren
- Prev by Date: Re: Select mit Alias
- Next by Date: Re: SQl-Mirror mit VB6
- Previous by thread: Re: Gebundene Controls aus ADO-Recordset aktualisieren
- Next by thread: Re: Gebundene Controls aus ADO-Recordset aktualisieren
- Index(es):
Relevant Pages
|
|
