Hallo! > >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. > > F�r parametrisierte Abfragen ist aber immer ein Command-Objekt n�tig, > oder? Im Moment stelle ich nur den SQL-String zusammen und �bergebe > den der ExecuteScalar Methode von DAAB. > Dann werde ich mir den Umgang mit dem Command-Objekt auch mal > anschauen.
Normalerweise greift man immer �ber ein Command-Objekt auf die Datenbank zu. Ein DataAdapter ist im Grunde auch nicht viel mehr als eine Collection von Command-Objekten. Die Datenbank bekommt einen SQL-Befehl, der im Command-Objekt aufbereitet wird. Gibt man dem Command-Objekt einen Tabellennamen als CommandText, wird automatisch "SELECT * FROM " davor gesetzt; �bergibt man einen Prozedurnamen, wird "EXECUTE " davor gesetzt, u.s.w. Viel mehr macht das Command-Objekt nicht. Wichtig ist allerdings noch, dass das Command-Objekt die von der Datenbank zur�ckgegebenen Werte einschlie�lich "RecordsAffected" aufbereitet und zwar entweder als Skalar oder als RowSet/Tabelle oder halt gar nicht. Ich kenne DAAB nicht und denke, dass es letztendlich auch einen CommandText zur Datenbank schickt. Wenn DAAB aber wirklich keine Parameter unterst�tzt, kann es m. E. nicht viel taugen. Parameter braucht man halt sowohl f�r einzelne SQL-Befehle als auch f�r Stored Procedures. Das Problem mit den Zusatzkomponenten ist halt auch, dass man nicht immer nachvollziehen kann, was in der BlackBox abl�uft und was dann letztendlich zur Datenbank geschickt wird. Das war unter ADO schon sehr schlimm. MS sei Dank ist ADO.NET viel einfacher. Freundliche Gr��e Joachim van de Bruck _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net
