Stored Procedures ohne Datasets

[daribla]

Stehe gerade etwas auf dem Schlauch beim Einarbeiten zu .net und Stored Procedures.

Vieleicht kann mir ja jemand ein paar Fragen beantworten:

- kann ich SP auch ohne Dataset, Tableadapter usw. direkt ansprechen und die zurückgeleiferten Datensätze anbinden? Hätte ich dann auch sowas wie DataRowState mit dem ich feststellen kann, ob der Datensatz geändert, gelöscht oder hinzugefügt wurde oder würde es direkt in der Datenbank gespeichert?

- wenn ich einen Tableadapter nutze und darin eine SP angebe, die mir Datensätze zurückliefert, dann wäre es doch besser in der Update Methode einer weitere SP anzugeben, die mir die Datensätze updated oder? Wenn ich die Update Methode, die das Command Objekt zur Verfügung stellt nutzen würde, würde dieser wieder ein SQL Command zusammenbauen und absetzen und der Vorteil der SP weg.

- Wenn ich eine Sp für Updates erstelle mit Parametern muss ich immer alle Parameter übergeben. Wie bekommt man es hin, das ich nicht immer alle Felder übergeben muss sondern entweder:
- ich nur die tatsächlich geänderten Felder übergebe (wie bekomme ich diese dann ermittelt?)
oder
- gar keine Felder übergeben muss und die SP mir einfach alle Felder Updatet ohne Rücksicht darauf, ob es tatsächlich geändert wurde


- wie ermittle ich mit SP Parallelitätskonflikte in Mehrbenutzeranwendungen?
- Führen SP intern Transaktionen durch und sperren den Datensatz bei änderungen und führen ein Rollback bei Problemen aus oder muss ich das selber in der SP Programmieren?

[Ralf Jansen]

zum DataRowState :

Der DataRowState ist ein Feature der ADO.Net Klassen. Ohne Verwendung der ADO.NEt Klassen also kein DataRowState. Es hindert dich aber niemand einen eigenen Klassenkonstrukt zu schreiben der den State nach hält.

zur Verwendung von Stored Procedures:

Kommt drauf an warum du Stored Procedures benutzen willst. Wenn es dir nur um den Performance Vorteil geht das SP's ~vor kompiliert~ sind solltest du im SP kein dynamisches SQL verwenden. Hast du in diesem Fall überhaupt mal ausprobiert ob sich in deinem konkreten Szenario ein Geschwindigkeitsvorteil ergibt? Ansonsten wäre der Aufwand ziemlich umsonst.

zu den Parallelitätskonflikte:
Bei SP's genauso wie bei direktem SQL. Indem du alle alten Felder in der WHERE Klausel des Update Statements verwendest. Wenn man den Datensatz dann zum updaten nicht findet, hast du einen Parallelitätskonflikt. Du musst also nicht nur alle neuen Werte an die SP übergeben sondern auch alle alten.

[daribla]

...Kommt drauf an warum du Stored Procedures benutzen willst. Wenn es dir nur um den Performance Vorteil geht das SP's ~vor kompiliert~ sind solltest du im SP kein dynamisches SQL verwenden.

Da ich sehr oft dynamisches SQl verwenden muss, wären dann wohl SP nicht sehr sinnvoll. Hatte mich auch schon gefragt, was für einen Sinn das vorcompilieren macht, wenn nicht alles Daten vorhanden sind (Parameter fehlen ja). Aber dann wiederum machen ja SP immer nur dann Sinn, wenn man keine Parameter übergibt, man also eine statische Prozedur hat oder?

Beim Auslesen hatte ich noch keine Geschwindigkeitsunterschiede feststellen können. (50000 Datensätze einmal über SP an Tableadapter und einmal SQL an Tableadapter)

[Ralf Jansen]

Aber dann wiederum machen ja SP immer nur dann Sinn, wenn man keine Parameter übergibt, man also eine statische Prozedur hat oder?

Wenn du die Parameter auch im SQL wiederum als Parameter verwendest helfen die sehr wohl. Nur wenn du dynamisches SQL verwendest, also Stringmanipulation am SQL Statement, dann hilft das nicht.