Hallo! > >es w�re dann also doch sinnvoll, das ganze �ber Stored Procedures > >zu machen, die die das Zur�ckliefern der @@IDENTITY gleich mit > >erledigen (nach dem Insert). > > Wenn ich hinter das Insert-Statement mit "; Select @@Identity" die ID > gleich auslese, ist es ja gleich nacheinander.
Das reicht v�llig! > >Im DAAB kannst Du dann in Deinen CRUD-Funktionen einen > >Output-Parameter deklarieren und damit die @@IDENTITY abholen. > >Hinsichtlich SQL-Injektion solltest Du sowieso mit Stored Procedures > >arbeiten. > > Wenn du meinst, werde ich das so machen. INSERT INTO ... (..., ..., ...) VALUES (p1, p2, p3); SELECT @@IDENTITY Gegen "SQL-Injection" helfen parametrisierte Abfrage genau so gut wie Stored Procedures. Wichtig ist, dass das Command-Object mit Parametern l�uft. Wenn man es dann mit .ExecuteScalar ausf�hrt, erh�lt man auch gleich den Identifier. Beim SqlDataAdapter l�uft das SELECT @@IDENTITY �brigens automatisch durch das Setzen einer Property. Da kann man dann auch gleich andere berechnete Werte zur�ckgeben lassen. Der Assistent erstellt wahlweise CommandText oder StoredProcedures. Sehr sch�n ist auch der CommandText f�r das "LogicalRecordLocking" bzw. zur Absicherung, dass der zu modifizierende Datensatz nicht zwischenzeitlich an anderer Stelle modifiziert wurde. > >Was ich zwischenzeitlich auch sehr gerne verwende, sind Typed > >DataSets, da hier der Datentyp im DataSet fixiert (entsprechend > >dem Typ in der DB) ist. > > Was bringt das f�r Vorteile? Da denke ich noch dr�ber nach. Bis jetzt ist mir nur eingefallen, dass man ggf. den automatisch erzeugten Code hinter dem Schema auch nutzen und modifizieren kann. Aber solche Modifikationen oder Erweiterungen geh�ren m. E. auch in die Datenbank wegen der Konsistenz. Auf jeden Fall kann man am "CodeBehind" des Schemas erkennen/lernen, was so alles getan werden kann oder muss und wie sich einzelne Properties auswirken. Hm, ich glaube doch, Datenlogik geh�rt sicherheitshalber in die Datenbank, oder? Freundliche Gr��e Joachim van de Bruck _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net
