Und selbst wenn du den unsauberen Weg gehst und reines SQL absetzen willst, haben das <a> und das <![CDATA[ ... ]]> da nichts zu suchen. Das soll in VB funktioniert haben?
ich vermute allerdings er sucht eigentlich nur nach einer Möglichkeit einen Multiline String zu benutzen.
var sql = @"
Select *
FROM Zeiterfassung.dbo.Mitarbeiter
";
Und was ist an reinem Sql unsauber? Der Zugriff mit dem EF ist natürlich schöner, aber überall da wo es auf Performance ankommt, gerade da wo es über mehrere Tabellen geht, kommt das EF einfach nicht mit. Und ich habe es oft versucht :(
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von unconnected am .
Doch das hat wunderbar funktioniert, fand das auch sehr übersichtlich.
Dim sqlCommandString As String = <![CDATA[
SELECT
AI.ViewCluster,
AI.Artikelnummer, A.Matchcode,
AI.Kanal AS Vertriebskanal,
ISNULL(AI.IsGrouped, 0) AS IsGrouped,
MGGFK.Sku_Gruppe AS GrpSKU,
CAST(AI.AngelegtAm AS DATE) AS AngelegtAm
FROM Artikelstammdaten.dbo.ArtikelImport AS AI
LEFT JOIN SL_MMETA.dbo.ART AS A
ON AI.Artikelnummer = A.Artikelnummer
LEFT JOIN Artikelstammdaten.dbo.MT_get_gruppiertXeinfach_from_Kanal(']]><%= Vertriebskanal %><![CDATA[') AS MGGFK
ON AI.Artikelnummer = MGGFK.Sku_Einfach COLLATE Latin1_General_CI_AS
WHERE Kanal = ']]><%= Vertriebskanal %><![CDATA['
ORDER BY ViewCluster, IsGrouped, Artikelnummer
]]>
Zitat von p!lle
Und selbst wenn du den unsauberen Weg gehst und reines SQL absetzen willst, haben das <a> und das <![CDATA[ ... ]]> da nichts zu suchen. Das soll in VB funktioniert haben? :baby:
soweit ich sehe hat keiner reines SQL abgelehnt. Lediglich die Parameter wurden an's Herz gelegt - und das hat keine Performanceeinbußen - sondern ganz konkrete Vorteile.
Soll ich mich jetzt einem der Beispiele von gfoidl witmen, oder habt ihr noch einen Vorschlag? Ich les ja jetzt nur das meine "alte" Vorgehensweise unsicher und schlecht ist? Wobei ich damit immer gut gefahren bin und aktuell auch nicht direkt weiß warum die unsicher sein sollte. Wenn es jetzt um Hochkommas oder dergleichen geht ist das absolut kein Ausschlusskriterium in meinen Augen.
Grüße
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von _Cashisclay am .
@_Cashisclay
Doch ist es.
Damit werden SQL Injections erst ermöglicht.
Und genau um dies zu vermeiden gibt es die SQL Parameter.
Lies dir den Beitrag durch und schau dir auch ein paar Beispiele im Netz an.
Es gab vor einigen Monaten auch einen Admin einer Webseite einer Ölfirma der auf C# ohne SQL Parameter aufgebaut hatte.
Seine Seite war dann relativ schnell nicht mehr nutzbar, weil eingie User einfach per SQL Injection die Datenbank gedroppt und somit gelöscht hatten.
@_Cashisclay Beim ersten Beispiel hattest Du keine Parameter. Das war noch in Ordnung. In deinem 2. Beispiel lötest Du die Parameter direkt per String concat in den Sql.
Das ist in mehreren Situationen fatal. Wobei Sql Injection wohl der grösste minus punkt ist.
Ein anderer ist z.B. die fehlerbehaftete Umwandlung von div. Datentypen nach string und zurück.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von unconnected am .
Um's zu verdeutlichen: Wer sowas wissentlich macht - provoziert geradezu einen Angriff. Sicher - dadurch dass es eine Eigenentwicklung ist, die am Ende wohl keinen juckt ist ein Angriff vll nicht ganz so wahrscheinlich - aber man riskiert diesen ohne jede Not. Dabei sind Parameter noch aus anderen Gründen absolut sinnvoll.
Was deine eigentliche Frage angeht: Hier scheint nach wie vor niemandem klar zu sein was genau du wissen möchtest... VB ist halt kein C# - aber das wundert ja auch dich nicht. Die Frage ist eher - was wolltest du uns mit den beiden VB-Fetzen sagen?
Wie ich das ganze in C# umsetzen kann, weil wenn ich das ganze ähniche versuche, scheitert es schon bei dieser CDATA Anweisung, da mir diese fehlerhaft angezeigt wird, würde mich trotzdem interessieren wie das geht, auch wenn man es offensichtlich anders umsetzen soll, was auch gut zu wissen ist.
Es macht keinen Sinn, dass Du mit Ach und Krach eine Art und Weise von VB in C# umsetzen willst.
In C# gibts für CDATA in SQL kein Äquivalent (weil nicht notwendig) und auch in VB hätte man immer mit Parametern arbeiten sollen.
Du hast Dir also von Anfangan, auch in VB, eine suboptimale, riskante und unsichere Umsetzung angeeignet.
Nein, der StringBuilder macht hier keinen Sinn; es ist bei einem parametrisierten SQL Befehl überhaupt nicht notwendig ihn dynamisch zusammen zu bauen.
Einfach als Konstante definieren, dann wird da auch sauberer ILCode draus.
Zusammen als Verbatim braucht man auch kein Concat bei Line Breaks.
private const string QUERY = @"
SELECT *
FROM Table1 AS T1
INNER JOIN Table2 AS T2 ON T1.ID = T2.T1ID
WHERE T1.VALUE = @P1
GROUP BY T2.OTHERVALUE
";
Warum sollte es das pauschal sein?
EF ist nur ein Provider von vielen - und nicht gerade der schnellste (bezogen auf EF6) oder mit vielen Features (EF Core).
Dafür mit wenig Aufwand (EF Core) für einfache, kleine Dinge praktisch.
Kommt doch immer drauf an, was man will - und braucht.
Und dafür gibt es den Prozess der Evaluierung.
Sorry meinte auch EF6, ich frag nur, weil das ganze via Direkt SQL zu machen irgendwie veraltet zu sein scheint. Jedenfalls wird es in meiner neuen Firma nicht praktiziert.
Veraltet nicht; es kommt halt drauf an, was man machen will.
Ich zB. vermeide jeglichen ORM, der mir das SQL generiert, weil es für meine/unsere Anforderungen einfach zu langsam ist (wir verwenden Dapper, kein EF).
Software auf dem Desktop zB. braucht i.d.R. nicht die Performance gegen eine Datenbank, wie es eine Cloud-Applikation benötigt.
Daher: immer brav evaluieren. Das ist nicht veraltet ;-)
Veraltet ist es nicht.
Es gibt sogar Fälle in denen es sinnvoller ist mit RAW SQL zu arbeiten als über einen OR Mapper zu gehen.
Gerade beim Thema Optimierung ist man manchmal besser als ein OR Mapper, auch wenn dieser Fall nicht immer vorliegen dürfte.
EDIT:
Abt war schneller ;)
T-Virus
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am .
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.