| 

.NET C# Java Javascript Exception

1
Hallo zusammen,
ist es möglich einen einfachen SQL Select-Command per Entity Framework abzusetzen. Absetzen heißt, Befehl an Datenbank schicken und eine Menge an Werten erhalten, wie man es halt von einem Select-Command her kennt. Ich rede hier von folgenden Statement:

SELECT A,B FROM TabelleC WHERE A LIKE 'ABC'

Ich brauche keine Parameter oder sonstiges und Linq hilft mir hier nicht weiter, weil das Statement individuell "zusammengebastelt" wird, d.h. ich weiß nie, welche Spalten durch den Benutzer selektiert werden sollen. Die Tabelle bleibt jedoch immer die selbe, nur ändern sich die Spalten.
Folgende Methode des Entity Framework liefert mir eine Exception:
ExecuteStoreQuery<TabelleC> (pSqlCommand, null)

Außerdem habe ich als Parameter null übergeben...
Eigentlich sollte das doch nicht so schwer sein oder?

Vielen Dank für eure Hilfe
20.07.2011
Gast
11 1 2
4 Antworten
2
Ich habe jetzt auf die schnelle nur zwei Links gefunden, aber vielleicht helfen dir die schon:

- execute t-sql direct in entity framework 3.5
- Execute T-SQL Statements in Entity Framework 4
20.07.2011
Dustin Klein 2,9k 2 9
2
Du kannst Dir aus dem Context das Connection Objekt holden und ein Command Object erstellen das mit dem gewünschten SQLString gefüttert wird, siehe Stack.. Eine gute Wahl um grössere Datenmenge zu löschen oder zu ändern.

Aber es ist auch möglich das etwas angestaubte Entity-SQL für dieses Szenario zu verwenden da es auf Strings basiert. siehe MSDN
20.07.2011
Jorgen Schumann 1,6k 2 9
1
Mal vor einer alternativen Antwort bzw. Vorgehen zuerst ne grundsätzliche Frage:

Ist ein ORM nicht genau dazu da, dass ich sowas nicht mehr mache/machen muss/soll?

Was ich da als Lösung sehe, ist herkömmliches ADO.NET, ein SqlCommand absetzen. Connection kannst ja bestimmt vom EF abgreifen?!? Wennst schon ne Datenstruktur fürs Ergebnis hast, schreibst halt nen Adapter.

Aber auch dabei rate ich zur Vorsicht, du taggst mit asp.net und fragst nach einem "individuell zusammengebastelten SQL Statement". Kannst Du ausschließen, dass dieser Code Opfer von z.B. SQL Injection Attacken wird?

Gruß
Florian
20.07.2011
ffordermaier 8,4k 3 9
1
Wenn er den zusammengebastelten String vorher bereinigen lässt und der String sich vielleicht auch nur aus einem Klickverhalten und nicht aus einer Benutzereingabe ergibt kann man sich da schon absichern. Generell hast du aber Recht und man sollte auf zusammengebastelte Statements verzichten.
Dustin Klein 20.07.2011
1
Sehe ich anders. Grundlegend ist es (meine Meinung nach) so, dass wenn ich z.B. eine große Datenmenge auslesen will, und diese sich dann auch noch über mehrere Tabellen erstreckt, dann ist wohl immer das direkt SQL-Statement einer EF-Abfrage vorzuziehen. Ich merke zurzeit auch, dass das EF eine feine Sache ist, aber gerade bei komplexen Datenstrukturen doch gravierende Probleme in der Handhabbarkeit aufzeigt.

Und zum Thema SQL-Injection schmeiße ich mal allgemein den Begriff "SQL-Command-Parameter" in den Raum. :)
SensenMannLE 20.07.2011
2
"man sollte auf zusammengebastelte Statements verzichten" Ja und Nein. Nehmen wir an ich habe eine View mit 6 Spalten (A,B,C,X,Y,Z) . Die Spalte X,Y und Z werden durch komplizierte Unterselects berechnet und brauchen somit viel Zeit zur Ausführung. Wenn ich jetzt "Select A,B,C,X,Y,Z from ..." ausführe aber nur die Spalten A und B brauche, werden alle anderen Spalten trotzdem berechnet. Wenn ich aber "Select A,B from ..." schreibe wird der SQL-Server die Spalten X,Y und Z nicht berechnen. Das Statement ist somit um ein vielfaches schneller.
Floyd 20.07.2011
Der Nachteil ist das ich dann mehr Statements im Procedure-Cache habe was bei Knappen Speicherrecourcen zum Problem werden könnte.
Floyd 20.07.2011
1
Freut mich, dass hier so ne lebendige Diskussion entsteht und die Dinge aus verschiedenen Perspektiven kommentiert werden. Nice :-)
ffordermaier 20.07.2011
1
@Floyd stimmt, da habe ich nicht alle Szenarios bedacht. Sehr gutes Beispiel, danke dir!
Dustin Klein 20.07.2011
@SensenMannLE: Geb ich Dir völlig Recht; ich meinte eigentlich, dass ich das dann eben nicht mit dem ORM machen sollte, sondern einen alternativen Weg suchen sollte, weil ich (ebenso wie Du) ein ORM für diesen Fall ungeeignet halte.
ffordermaier 20.07.2011
0
- Antwort bitte löschen -.-
20.07.2011
Dustin Klein 2,9k 2 9
Ohne Kaffee klickt man dann auch schonmal auf "Antworten" statt "Kommentieren" ...
Dustin Klein 20.07.2011

Stelle deine .net-Frage jetzt!