Hallo!
> ich hatte das adOpenKeySet nach Deiner Mail von eben an Mansur
>
> >Auf keinen Fall brauchst Du den Keyset-Cursor. Der ist f�rs Web viel
zu
> aufwendig.
>
> herausgenommen und festgestellt das es eben auch ohne KeySet l�uft.
>
> Weiterhin habe ich Deinen Tipp
>
> adCmdText anstelle von adCmdTable ("Befehl ist der Name der Tabelle"
---was das auch immer hei�t
> wei� ich nicht) und adOpenStatic anstelle von adOpenKeySet ausprobiert
>
> Fehlermeldung:
> .... Select, Update, Delete erwartet ...
Tats�chlich arbeite ich beim Update und AddNew ausschlie�lich mit
adOpenStatic und adLockOptimistic. Dabei ist es egal, ob ich das
Recordset mit adCmdText oder mit adCmdTable anfordere. Bei adCmdText
enh�lt der SQL Parameter eine g�ltige SQL-Abfrage, bei adCmdTable
dagegen lediglich den Tabellen- oder View-Namen.
> also wieder auf adCmdTable umgestellt und adOpenKeySet wieder
eingef�gt
adCmdText erwartet einen Befehl (in diesem Fall ein SELECT, wie ich auch
vorgeschlagen habe), wenn Du nur den Tabellennamen angibst, solltest Du
adCmdTable als Parameter verwenden. In dem Fall wird aber unn�tigerweise
die ganze Tabelle ins Recordset geschaufelt, was zwar funktioniert, aber
v�llig �berfl�ssig ist, oder?
> Danach noch einmal in meiner ASP-Bibel gelesen und sende folgenden
>
> Auszug aus T. Weltner Activ Server Pages lernen und beherrschen Seite
281
>
> Forward-only ("Firehorse",Standard)
> Schnellster Recordset-Typ, der nur in eine Richtung gelesen werden
kann ...
>
> Static Cursor
> Recordset enth�lt nur eine feste Ergebnisse, die nicht ver�ndert
werden kann.
> Neue Datens�tze, die Sie der Tabelle hinzuf�gen, werden in diesem
Recordset nicht reflektiert
> ------ hei�t meines Erachtens (d. h. eine neu vergebene ID kann nicht
ausgelesen werden)......
Falsch, �nderungen ANDERER Nutzer am Datensatz werden nicht angezeigt,
was auch unn�tig ist: F�r ein AddNew brauchst Du nicht zu wissen, was
gleichzeitig andere Benutzer mit anderen Datens�tzen anstellen, oder?
> KeySet Cursor
> Recordset verh�lt sich wie ein Static Cursor, jedoch werden �nderungen
ber�cksichtigt, die Sie an
> der Tabelle vornehmen. �nderungen die andere Anwender zur gleichen
Zeit vornehmen, bleiben dagegen
> unber�cksichtigt.
> ---------- neue ID k�nnen ausgelesen werden --------------------
Hier irrt Weltner und steht im Widerspruch zur Dokumentation und anderen
B�chern (und zu meinen Erfahrungen):
Durch ADO gibt es 3 Speicherr�ume. Der erste ist die Datenbank, der 2.
das Recordset und der 3. ist unsere Applikation.
Der ForwardOnly-C�rsor liest Daten aus der Datenbank und schreibt Sie
ohne Brimborium in das Recordset, so dass die Applikation die Daten
lediglich sequentiell lesen und nicht ver�ndern kann. Deshalb ist das
Ding so schnell (Firehose) und ideal f�r alle DB-Abfragen, vor allem in
Verbindung mit Views/Abfragen.
Der Static-Cursor liest Daten aus der Datenbank und schreibt Sie mit
Zusatzinformationen (auch AutoIncrement) in das Recordset. Die
Applikation liest beliebig und stellt auch neue Daten ins Recordset, die
dann von ADO an die Datenbank weitergegeben werden. Das Ding hei�t
Static, weil �nderungen ANDERER Benutzer an der Datenbank nicht ins
Recordset aufgenommen werden, eigene aber sehr wohl. Fr�her hie� dieser
Cursor "Snapshot", weil er quasi eine Momentaufnahme einer Datenbank
darstellt.
Beim Dynamic-Cursor wird das Recordset laufend aktualisert, um
�nderungen ANDERER Benutzer anzuzeigen. Tats�chlich geschieht das
dadurch, dass ADO permanent die Datenbank fragt, ob andere Besucher was
�ndern, bzw. dadurch, dass die Datenbank eine �nderungsmitteilung an ADO
schickt, so dass ADO, das Recordset neu abfragen kann. So etwas ist sehr
wichtig, wenn in einer Client/Server-Umgebung mehrere Benutzer
gleichzeitig an Daten arbeiten, die sich gegenseitig beeinflussen.
Der Keyset-Cursor verh�lt sich wie ein Dynamic-Cursor, nur dass das
Recordset lediglich die Schl�sseldaten enth�lt und der Rest direkt mit
der Datenbank abgearbeitet wird. Insofern ist der Keyset-Cursor
ebenfalls f�r Client/Server-Anwendungen gedacht.
Im Web arbeiten zwei Anwender nur in Ausnahmef�llen am gleichen
Datensatz. Also braucht es auch keinen Dynamic- oder Keyset-Cursor,
zumal zwischen Lesen (Anzeigen im Browser) und Schreiben (�nderungen vom
Bildschirm) die Datenbankverbindung in der Regel gekappt wird. Dynamic
und Keyset machen nur Sinn, wenn die Verbindung aufrecht gehalten wird.
F�r das Lesen zum Anzeigen reicht der ForwardOnly-Cursor, weil
�nderungen der Benutzer nicht sofort zur�ckgegeben werden. Wenn das
Webformular die �nderungen zur�ckgibt, muss lediglich der zu �ndernde
Datensatz mit OpenStatic gelesen werden. F�r das AddNew reicht ein
leeres Recordset (select * from ... where id < 0).
rs.Open "select ... from ... where ...", db, adOpenForwardOnly,
adLockReadOnly, adCmdText
oder
rs.Open "viewname", db, adOpenForwardOnly, adLockreadOnly, adCmdTable
---> Anzeige am Bildschirm
rs.Open "select ... from ... where id < 0", db, adOpenStatic,
adLockOptimistic, adCmdText
---> leeres Recordset f�r AddNew
rs.Open "select ... from ... where id = ...", db, adOpenStatic,
adLockOptimistic, adCmdText
---> Recordset mit 1 Record f�r Update oder Delete
Mehr braucht es im Web in der Regel nicht. Wichtig ist dann nur noch die
CursorLocation, wobei ich f�r das Web ausschlie�lich den adUseClient
empfehle. ADO k�mmert sich dann auch vorbildlich um
Datenkonvertierungen.
> Dynamic Cursor
> Aufwendigster Cursortyp: Zus�tzlich zum KeySet Cursor ber�cksichtigt
dieses Recordset auch
> �nderungen an der Tabelle, die andere Benutzer vornehmen. ......
Wie bereits beschrieben, ist Keyset aufwendiger in der Konstruktion,
daf�r aber gehen weniger Daten �ber die Leitung.
Freundliche Gr��e
Joachim van de Bruck
| [aspdedatabase] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
