Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Gibt es CDATA für Datenbankabfragen aus VB auch für C#?
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

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

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 7559
Herkunft: Waidring

beantworten | zitieren | melden

Hallo _Cashisclay,

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

mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
p!lle
myCSharp.de - Member

Avatar #avatar-3556.jpg


Dabei seit:
Beiträge: 1053

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
unconnected
myCSharp.de - Member

Avatar #avatar-3200.jpg


Dabei seit:
Beiträge: 862
Herkunft: Oerlinghausen/NRW

beantworten | zitieren | melden

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 :(
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von unconnected am .
private Nachricht | Beiträge des Benutzers
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

beantworten | zitieren | melden

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:
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

Zitat von unconnected

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

beantworten | zitieren | melden

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 .

Moderationshinweis von Abt (18.06.2018 - 15:52:17):

Keine Full Quotes
[Hinweis] Wie poste ich richtig?

private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1892
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

@_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
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.
private Nachricht | Beiträge des Benutzers
unconnected
myCSharp.de - Member

Avatar #avatar-3200.jpg


Dabei seit:
Beiträge: 862
Herkunft: Oerlinghausen/NRW

beantworten | zitieren | melden

@_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 .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

Zitat von _Cashisclay
Wobei ich damit immer gut gefahren bin

Das war bisher dann reines Glück.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von Taipi88 am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

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
     ";
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

beantworten | zitieren | melden

Besser wäre es wahrscheinlich direkt mit dem EF zu arbeiten?
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
_Cashisclay
myCSharp.de - Member



Dabei seit:
Beiträge: 279

Themenstarter:

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16103

beantworten | zitieren | melden

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 ;-)
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1892
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers