Hallo Joachim, hmm... jetzt weiss ich zwar die Hintergr�nde, aber immer noch nicht genau, wie der Code denn aufgebaut sein muss (sorry f�r mein Unverst�ndnis aber das Cursor-Setzen ist sozusagen "Neuland" f�r mich).
Ich mache drei Inserts in drei verschiedene Tables. Bei den ersten zwei brauche ich die AutoID, um diese in der dritten Tabelle mit anderen Daten zu verkn�pfen. Die ersten zwei Inserts habe ich nach dem besagten Artikel aufgebaut. Beim ersten Insert bekomme ich die AutoID nicht, beim zweiten schon (obwohl eigentlich genau gleich). So f�llt mein dritter Insert nat�rlich auf die Nase.... Muss ich denn jetzt statt RS.CursorLocation = 2 'adUseServer RS.CursorType = 1 'adOpenKeyset RS.LockType = 3 'adLockOptimistic dieses hier machen? RSOrg.CursorLocation = adUseClient RSOrg.CursorType = adOpenStatic RSOrg.LockType = adLockOptimistic *dummfrag* ?????? Jutta ----- Original Message ----- From: "Joachim van de Bruck" <[EMAIL PROTECTED]> To: "ASP Datenbankprogrammierung" <[EMAIL PROTECTED]> Sent: Sunday, January 27, 2002 2:25 PM Subject: [aspdedatabase] AW: Re: AW: ID bleibt nach update empty > 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!!!). > > Das Problem mit dem Lesen automatisch eingesetzter Werte ist eigentlich > recht simple: Man muss den Wert lesen, also der Datenbank einen Befehl > geben, diesen Wert zur�ckzugeben. > > ADO macht das automatisch, bei > ClientSide-Static-Cursor ODER > Property(Update_Resync) = adResyncAutoincrement > > Abh�ngig vom Datenbanktreiber werden bestimmte Properties und andere > Eigenschaften automatisch gesetzt. So kann es sein, dass eine Funktion > mit Access funktioniert und mit SQL Server nicht oder umgekehrt. Das ist > die ADO-Falle, weshalb ich eigentlich grunds�tzlich Prozeduren so > aufrufe, dass ADO keine Default-Werte einsetzen muss, also mit allen > Parametern. > > Im Web verwende ich fast ausschlie�lich den ClientSide-Cursor, damit ADO > die Verantwortung f�r das Recordset hat und meine Applikationen sowohl > mit Access als auch mit SQL-Server arbeiten. So fordert ADO auch den > Autoincrementwert beim Insert gleich mit an. > > Der ServerSide-Cursor kann in einigen Situation performanter sein, aber > ganz selten im Web. Er ist z. B. dann n�tzlich, wenn mehrere Benutzer > gleichzeitig eine Tabelle modifizieren. In Verbindung mit dem Dynamic- > oder Keyset-Cursor schickt die Datenbank dann alle Modifikationen an > alle Benutzer und aktualisiert laufend die Recordsets der Clients oder > schickt auch Autoincrementwerte zur�ck. Nat�rlich enthielt das Recordset > im vorliegenden Fall auch den korrekten Autoincrementwert, aber ADO hat > sich nicht darum gek�mmert und deshalb kann das Script den Wert auch > nicht lesen. > > Es ist also nicht unbedeutend, welchen Datenbankcursor (ForwardOnly, > Static, Dynamic, Keyset) man verwendet und wer die Verantwortung daf�r > hat (ADO = Client, Datenbankengine = Server). Meine Buchempfehlung dazu: > > David Sceppa: ADO-Programmierung. > > Und nat�rlich steht das auch in der MSDN unter ADO und in den > Technischen Artikeln. > > 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 | [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
