Gibt es CDATA für Datenbankabfragen aus VB auch für C#?

Hallo zusammen,

mal eine allgemein recht simple Frage, ich hab in VB immer für SQL Abfragen CDATA benutzt.

Das sah dann so aus ->

Dim sqlCommandString As String =<![CDATA[

Select * FROM Zeiterfassung.dbo.Mitarbeiter

]]

Gibt es das in der Form nicht für C#?

Grüße

Hallo _Cashisclay,

kennst du [Artikelserie] SQL: Parameter von Befehlen ? Damit sollte deine Frage geklärt werden und gleichzeitig guter Programmierstil gelehrt werden.

mfG Gü

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? 🤔

Ja, hat es..

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 😦

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

                                                    ]]>

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? 👶

Hi,

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.

LG

Und was ist an reinem Sql unsauber? Der Zugriff mit dem EF ist natürlich schöner, aber

Niemand hat von EF gesprochen - jedoch aber von sicherem SQL und Parametern.

Und das Beispiel _Cashisclay von ist leider alles andere als sicher - und absolut zu vermeiden.
"Funktioniert" alleine ist kein Qualitätsmerkmal.

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

@_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.

Hier noch nützliche Links dazu:
SQL-Injection
https://www.w3schools.com/sql/sql_injection.asp

T-Virus

@_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.

Wobei ich damit immer gut gefahren bin

Das war bisher dann reines Glück.

Hi,

als Beispiel - um zu verdeutlichen wie viele solche Fehler machen und was dabei rausgekommen ist:

https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/

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?

LG

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.

Grüße

Mach es so, wie es C# vorsieht.

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.

Hi,

die Frage ergibt für mich immer noch keinen Sinn - aber - um mich an deine beiden Codebeispiele zu halten:

Zu 1)

string sqlCommandString = "Select * FROM Zeiterfassung.dbo.Mitarbeiter";

Zu 2 (Beachte "@Vertriebskanal" - das verwendet eventuell übergebene Parameter)

string sqlCommandString = "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) AS MGGFK" +
"ON AI.Artikelnummer = MGGFK.Sku_Einfach COLLATE Latin1_General_CI_AS" +
"WHERE Kanal @Vertriebskanal" +
"ORDER BY ViewCluster, IsGrouped, Artikelnummer";

Hinweis: Bei längeren Befehlen (ich war hier zu faul dafür) empfiehlt es sich eigentlich den StringBuilder zu verwenden im Sinne von:

StringBuilder sb = new StringBuilder();
sb.AppendLine("mytext1");
sb.AppendLine("mytext2");
sb.AppendLine("mytext3");

Wie man so etwas dann ausführt - kannst du z.B. auf folgender Seite nachlesen (übrigens beim verlinkten FAQ-Eintrag über Parameter auch verlinkt):
http://openbook.rheinwerk-verlag.de/visual_csharp/visual_csharp_26_003.htm#mjaed852f5e366e95ecd103ddabd86eec1

Kurzform für Mssql:

using (SqlConnection connection = new SqlConnection(ConnectionSting))
  {
    connection.Open();

    using (SqlCommand cmd = new SqlCommand(sqlCommandString, connection))
    {
      cmd.Parameters.AddWithValue("@Vertriebskanal", <DeinVertriebskanal>);
      return cmd.ExecuteNonQuery();
    }
}

LG

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
     ";

Besser wäre es wahrscheinlich direkt mit dem EF zu arbeiten?

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