Hallo! > > Also der Artikel ist kein Schmarr'n, er ist halt nur nicht vollst�ndig > > und beschreibt meines Erachtens auch keine optimale L�sung f�r's Web > > (Keyset-Cursor!!!). > > also �ber den keyset-cursor mag man ja je nach anwendungsfall > noch geteilter meinung sein, > mich hat aber folgender satz v�llig verunsichert:
N�, die Vorteile des Keyset-Cursors hat man ja nur, wenn die Connection nicht st�ndig auf - und abgebaut wird. Keyset hat im Web nichts zu suchen. ;-) > Das Setzen der CursorLocation auf adUseServer bewirkt, da� der Recordset > Cursor von der Datenbank, und nicht von ADO oder dem Datenbankprovider (wie > ODBC oder OLE DB), verwaltet wird. Dies ist notwendig, um direkten Zugriff auf > den von der Datenbank automatisch generierten ID-Wert zu erhalten Das ist nur eine M�glichkeit, die aber wahrscheinlich nur abh�ngig vom Treiber und der Datenbank funktioniert. Ich beneide die Leute, die solche Artikel schreiben k�nnen, und m�chte sie deshalb auch in Schutz nehmen. F�r mich ist es einfacher, auf Fragen und damit auf konkrete F�lle zu antworten, als Artikel zu schreiben, die umfassend und allgemeing�ltig sind. Vieles ist doch sehr vielschichtig und kann in kleinen Artikeln nicht abgearbeitet werden. > nun verwendet das beispiel dsn aber es funktioniert hier > (mit oledb) definitiv _nicht_ > bleiben zwei m�glichkeiten: oledb vertr�gt den server-cursor nicht, > oder ich habe ein konfigurationsproblem > _notwendig_ ist adUseServer jedendfalls nicht > > > > ADO macht das automatisch, bei > > ClientSide-Static-Cursor ODER > > Property(Update_Resync) = adResyncAutoincrement > > dar�ber bin ich heute schon gestolpert, wusste dann aber > nicht wie setzen > > > > Und nat�rlich steht das auch in der MSDN unter ADO und in den > > Technischen Artikeln. > > ... wo ich mich vorher nat�rlich schon herumgetrieben habe ;-) > > deine erl�uterungen sind - wie immer - sehr hilfreich, deutest > du damit an, dass es auch bei einem insert-statement eine > m�glichkeit gibt, die id wieder auszulesen? Ja und Nein! Bei einem "INSERT" �ber db.Connection oder db.Command funktioniert das nicht. Irgendjemand muss den Befehl zum Lesen ja absetzen. Mit selbst zusammengestellten SQL-Strings, die ADO ja nur an die Datenbank weiterleitet, funktioniert das nicht. Im SQL-Server kann man daf�r eine Stored Procedure schreiben, die dann mit "SELECT @@Identity"" die Id zur�ckgibt. Aber ich bin grunds�tzlich dagegen, SQL-Befehle in VBScript zu generieren. Man findet solche Beispiele h�ufig. Ich kann C++-Programmierer verstehen, die sagen, dass ADO f�r sie zu langsam ist und dass sie das bisschen SQL lieber selber machen. Aber ADO ist mit Sicherheit schneller als VBScript. Deshalb sollte man auch in ASP/VBScript immer ausgiebig ADO einsetzen. Die urspr�nglich einzige Aufgabe von ADO war, Datenbankunabh�ngigen Code zu erm�glichen. Im Web bringt ADO zus�tzlich Performanz bei Verwendung von interpretierten Sprachen. Auf ein stichhaltiges Argument gegen "rs.AddNew array(), array()" warte ich immer noch. Aber es gibt viele Argemente gegen "INSERT ...": Performanz, Typumwandlung, Abh�ngigkeit von Datenbank, ... > und um auf die sache mit den arrays nochmal zur�ckzukommen: > du meinst, lieber NULL einf�gen als einzelne felder ist > performanter - sonst m�sste ich mir das fields-array ja > vorher auch irgendwie dynamisch generieren (und ja, du hast > v�llig recht, wenn du �ber string = string & ... konstrukte > herziehst) - war da nicht irgendwas mit array.append? Was ist schneller? Maschinennaher Code in ADO oder interpretiertes VBScript? Array.Append gibt es in VBScript nicht. Das muss man selber schreiben, was aber nicht viel Sinn macht. Wenn man dynamische Listen braucht, nimmt man Recordsets oder Dictionaries. 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
