[ASP.NET] Variabelen in query plaatsen

[Verwijderd]

Hoe krijg ik het voor elkaar een variabele in een query te plaatsten?

Via PHP was het makkelijk omdat je gebruik maakte van $variabele, bij C# is het natuurlijk gewoon tekst wanneer je programmeerd.

Dit is mijn query tot nu toe:

string sql = "UPDATE admin SET email = sql_email WHERE id='1'";

sql_email is dus die variabelen die in het project een tekstbox is die ik zo uitlees:
string sql_email = input_email.Text;

[ Voor 37% gewijzigd door Verwijderd op 05-06-2006 17:48 ]

[Cyphax]

Nouja, in PHP is de operand "." en bij C# is dat "+".
Dan krijg je dus bijvoorbeeld

code:

query = "select * from table where bla='" + bla + "'"

ofzo.
Pas dat maar eens toe in jouw code nu, dan zou je er helemaal uit moeten komen.

[ Voor 120% gewijzigd door Cyphax op 05-06-2006 17:51 ]

[BM]

C#:

SqlCommand cmd = new SqlCommand("UPDATE admin SET email = @Email WHERE id='1';",[sqlconnectie hier]);
cmd.parameters.add("@Email",SqlDbType.NVarChar,25).value = sql_email;
//connectie openen;
cmd.executenonquery();
//connectie sluiten.

Dat is de netste manier volgens mij
Het aan elkaar plakken van strings om zo een query op te bouwen is nogal foutgevoelig.

[ Voor 19% gewijzigd door BM op 05-06-2006 17:52 ]

[NMe]

Wat Cyphax zegt. [google=c# string concatenation example]

Maar ik denk dat je beter ook eens kan kijken naar stored procedures, als je database dat ondersteunt.

edit:
Anders zijn ze me even voor...

[ Voor 13% gewijzigd door NMe op 05-06-2006 17:52 ]

[Cyphax]

BM schreef op maandag 05 juni 2006 @ 17:52:

C#:

SqlCommand cmd = new SqlCommand("UPDATE admin SET email = @Email WHERE id='1';",[sqlconnectie hier]);
cmd.parameters.add("@Email",SqlDbType.NVarChar,25).value = sql_email;
//connectie openen;
cmd.executenonquery();
//connectie sluiten.

Dat is de netste manier volgens mij
Het aan elkaar plakken van strings om zo een query op te bouwen is nogal foutgevoelig.

Als je de strings eerst escaped etc lijkt me dat niet zo'n punt, toch?
(voor je ze in de query plakt dus)

[ Voor 8% gewijzigd door Cyphax op 05-06-2006 17:53 ]

[BM]

Cyphax schreef op maandag 05 juni 2006 @ 17:53:
[...]

Als je de strings eerst escaped etc lijkt me dat niet zo'n punt, toch?
(voor je ze in de query plakt dus)

Daar zul je de foutgevoeligheid misschien mee afvangen, maar ik blijf het (persoonlijk) niet echt netjes vinden

[Verwijderd]

Precies, waarom zou je de nettere, veiligere parametrized query functionaliteit niet gebruiken als 'ie toch standaard in het .NET framework is ingebakken?

[whoami]

-NMe- schreef op maandag 05 juni 2006 @ 17:52:
Wat Cyphax zegt. [google=c# string concatenation example]

Maar ik denk dat je beter ook eens kan kijken naar stored procedures, als je database dat ondersteunt.

edit:
Anders zijn ze me even voor...

Waarom zouden Stored Procedures beter zijn ?
Je kan in .NET perfect embedded SQL gebruiken mbhv parametrized queries; dat is even veilig als SP's.
Daarnaast ben je ook een stuk flexibeler.
En als je mooi een data-access layer maakt, dan zijn je queries ook niet over je app verspreid.

Als je de strings eerst escaped etc lijkt me dat niet zo'n punt, toch?
(voor je ze in de query plakt dus)

Gebruik maken van string concatenation is:
- niet goed voor performance (caching van exec. plans)
- onduidelijk
- toch een kans op sql injection

klik

[ Voor 25% gewijzigd door whoami op 05-06-2006 19:33 ]

[Cyphax]

whoami schreef op maandag 05 juni 2006 @ 19:27:
Gebruik maken van string concatenation is:
- niet goed voor performance (caching van exec. plans)

Wat heeft je code met caching van execution plans op de databaseserver te maken?
Voert die oledb-code nog meer uit op de achtergrond ofzo?

- onduidelijk

Hmmm dat hangt er naar mijn mening nog maar vanaf. Voor kleinere queries vind ik dat niet per definitie waar.
Voor wat ingewikkelder queries wel.

- toch een kans op sql injection

Want...? Als je je data goed escaped toch niet? Dat komt uit het artikel ook niet naar voren.
Uiteraard ben ik het er wel mee eens dat het good practice is als de beschikking erover hebt.
(die heb ik dus nooit )

[ Voor 16% gewijzigd door Cyphax op 05-06-2006 20:46 ]

[whoami]

Cyphax schreef op maandag 05 juni 2006 @ 20:44:
[...]

Wat heeft je code met caching van execution plans op de databaseserver te maken?
Voert die oledb-code nog meer uit op de achtergrond ofzo?

Een DBMS kan execution plans van queries cachen als die query hetzelfde is; dmv die parameters is die query hetzelfde.

Hmmm dat hangt er naar mijn mening nog maar vanaf. Voor kleinere queries vind ik dat niet per definitie waar.
Voor wat ingewikkelder queries wel.

Ook voor simpele queries; en stel je eens de problemen voor met datums in je query.

Want...? Als je je data goed escaped toch niet? Dat komt uit het artikel ook niet naar voren.
Uiteraard ben ik het er wel mee eens dat het good practice is als de beschikking erover hebt.
(die heb ik dus nooit )

En wat als je het escapen vergeet ?

[Cyphax]

whoami schreef op maandag 05 juni 2006 @ 20:50:
[...]
Een DBMS kan execution plans van queries cachen als die query hetzelfde is; dmv die parameters is die query hetzelfde.

Dat is handig, maar datzelfde geldt toch voor een query die je met string concatenation samenstelt? MAW: die levert toch ook steeds dezelfde query op?

Ook voor simpele queries; en stel je eens de problemen voor met datums in je query.

Datums zijn idd nogal onhandig.

En wat als je het escapen vergeet ?

Dan ben je aan het prutsen.
Nogmaals: als je de beschikking erover hebt is het verstandiger om die functionaliteit te gebruiken, maar die heb je niet altijd. Dan zou ik wel willen weten hoe ik het beste m'n queries opbouw.

Daarnaast hoop ik dat dit soort functionaliteit geen luie developers oplevert. Ik zie in die voorbeelden altijd dat men "' drop database;" oid toevoegt. En als dat kan heb je al een fout gemaakt.
Maar het wordt nou nogal off-topic geloof ik.

whoami schreef op maandag 05 juni 2006 @ 19:27:

Waarom zouden Stored Procedures beter zijn ?

Niet, hij bedoelde parametrized queries maar hij vindt het zo dom overkomen als ie dat nu verandert. Zegt ie zelf althans.

[ Voor 14% gewijzigd door Cyphax op 05-06-2006 21:31 ]

[Janoz]

Cyphax schreef op maandag 05 juni 2006 @ 21:26:
Dat is handig, maar datzelfde geldt toch voor een query die je met string concatenation samenstelt? MAW: die levert toch ook steeds dezelfde query op?

Nope, bij een geconcatteneerde string weet de db laag niet wat variabel is en wat vast. Zodra je bv id=1 veranderd in id=2 heb je een andere query. Bij parametrized queries krijgt de db een query en een set parameters. De query is in dat geval altijd hetzelfde en alleen de parameters verschillen.

Dan ben je aan het prutsen.

Het si ondoenelijk om nooit een fout te maken wanneer je je variabelen constant alle kanten op moet converteren. Data is data. De manier waarop het op sommige plekken nodig is zou door die plekken afgehandeld moeten worden. Wil ik html schrijven dan wil ik dat mijn html schrijf methode de escaping afhandeld. Wil ik dingen naar de database gooien dan zorgt mijn database laag er wel voor dat het netjes gevormd wordt.

Nogmaals: als je de beschikking erover hebt is het verstandiger om die functionaliteit te gebruiken, maar die heb je niet altijd. Dan zou ik wel willen weten hoe ik het beste m'n queries opbouw.

Als je ze niet tot je beschikking hebt, dan heb je inderdaad weinig keuze.

Daarnaast hoop ik dat dit soort functionaliteit geen luie developers oplevert. Ik zie in die voorbeelden altijd dat men "' drop database;" oid toevoegt. En als dat kan heb je al een fout gemaakt.
Maar het wordt nou nogal off-topic geloof ik.

Dit heeft weinig met luiheid van developers te maken. Het heen en weer converteren maakt je code alleen maar onduidelijk en onleesbaar. Daarnaast kost het alleen maar performance terwijl een database connectie misschien wel zelf een veel efficientere methode heeft om bijvoorbeeld een byte array die kant op te krijgen (terwijl jij hem eers nog base64 moet encoden om hem uberhaupt een string in te krijgen)

[Verwijderd]

Bedankt voor al jullie reacties, ik heb de code nu aangepast en hij werkt zonder fouten alleen slaat hij de gegevens die ik invoer niet op.

Ik heb nu de volgende code:

string input_email_code = input_email.Text;
string connString = @"CONNECTIESTRING";
string sql = "UPDATE admin SET email = @sqlemail WHERE id='1'";
SqlConnection conn = new SqlConnection(connString);
SqlCommand command = new SqlCommand(sql, conn);
command.Parameters.Add("@sqlemail", SqlDbType.VarChar, 25).Value = input_email_code;
conn.Open();
command.ExecuteNonQuery();
conn.Close();

Hij lijkt mij zo in orde alleen dat is hij dus niet

[Verwijderd]

Verwijderd schreef op maandag 05 juni 2006 @ 22:58:
Bedankt voor al jullie reacties, ik heb de code nu aangepast en hij werkt zonder fouten alleen slaat hij de gegevens die ik invoer niet op.

Ik heb nu de volgende code:

[...]


Hij lijkt mij zo in orde alleen dat is hij dus niet

Ik zie niet zo snel waar dan de fout zit? (maar misschien ben ik gewoon te moe)

[TeeDee]

Is je Id een string of een int? Er staan nu een ' om je Id waarde. Misschien is dat het probleem.

[Cyphax]

TeeDee schreef op dinsdag 06 juni 2006 @ 09:58:
Is je Id een string of een int? Er staan nu een ' om je Id waarde. Misschien is dat het probleem.

MSSQL vindt dat niet zo'n punt, dat moet wel gewoon werken.

Misschien is de connection string niet goed? Die heb je eruit gehaald om 'm niet prijs te geven neem ik aan.

[ Voor 20% gewijzigd door Cyphax op 06-06-2006 10:08 ]

[whoami]

Als je veld een integer is, zet je er geen quotes rond. Of MS-SQL dat nu een punt vind of niet...
Ik weet trouwens niet of MS-SQL deze 2 als hetzelfde aanziet:

code:

'1 '

code:

'1'

Wat nu staat er volgens mij ook een spatie tussen 1 en '.
Dus: als je veld een integer is, laat die quotes rond 1 gewoon weg.

Cyphax: als de connectie-string niet goed is, dan zou je gewoon een exceptie krijgen bij het openen van de connectie.

[Cyphax]

whoami schreef op dinsdag 06 juni 2006 @ 10:16:
Als je veld een integer is, zet je er geen quotes rond. Of MS-SQL dat nu een punt vind of niet...

Evengoed is dat niet de reden dat het nu fout gaat en daar gaat het nu even om. Zullen we even niet teveel afdwalen?

Ik weet trouwens niet of MS-SQL deze 2 als hetzelfde aanziet:

code:

'1 '

code:

'1'

Wat nu staat er volgens mij ook een spatie tussen 1 en '.

Nee, dat maakt geen verschil. MSSQL converteert zelf de varchar naar int, en als dat niet lukt krijg je een foutmelding terug. Trimmen doet ie wel zonder morren.

Cyphax: als de connectie-string niet goed is, dan zou je gewoon een exceptie krijgen bij het openen van de connectie.

Da's wel zo. Hij krijgt geen foutmelding, dus de code is in orde, maar misschien komt ie geen match tegen met die where-clause. Of de query moet helemaal niet uitgevoerd worden

[ Voor 18% gewijzigd door Cyphax op 06-06-2006 10:26 ]

[whoami]

Cyphax schreef op dinsdag 06 juni 2006 @ 10:24:
[...]

Evengoed is dat niet de reden dat het nu fout gaat en daar gaat het nu even om. Zullen we even niet teveel afdwalen?

Doen we dat dan ?
Het is zowiezo netter om die quotes weg te laten (ook qua performance), dus waarom zou dit niet mogen gezegd worden ?
Trouwens, mochten we teveel afdwalen dan zou ik - of een andere mod - dat wel ff melden.

Een andere reden: de query wordt wel uitgevoerd, maar met verkeerde waarden. Neem de profiler er eens bij, en check eens wat er naar de DB gestuurd wordt. Debug eventueel je applicatie, en kijk eens wat er gebeurd; als je gebruik maakt van ASP.NET vang je misschien de postback niet op, waardoor je iedere keer updated met de waarden die zich in de DB bevinden, ipv de waardes die je opgegeven hebt ? (Maw, misschien worden de oorspronkelijke gegevens opnieuw uit de DB gehaald, en gebruik je die om te updaten ? )

maar misschien komt ie geen match tegen met die where-clause. Of de query moet helemaal niet uitgevoerd worden

Maar, dat heeft niets met de connection-string te maken.

[ Voor 9% gewijzigd door whoami op 06-06-2006 10:33 ]

[Cyphax]

whoami schreef op dinsdag 06 juni 2006 @ 10:32:
[...]

Doen we dat dan ?
Het is zowiezo netter om die quotes weg te laten (ook qua performance), dus waarom zou dit niet mogen gezegd worden ?

Je doet net alsof ik je op de vingers tik ofzo. Het gaat er niet om of het gezegd mag worden of niet maar je kwam een tikkie aanvallerig over, en daarbij zou het jammer zijn als het probleem van X-Ploit ondersneeuwt door je tips.

Trouwens, mochten we teveel afdwalen dan zou ik - of een andere mod - dat wel ff melden.

Nounou.
Til er niet te zwaar aan hoor.

Maar, dat heeft niets met de connection-string te maken.

Nope, maar dat zeg ik ook niet (of ik moet mezelf ongelukkig verwoord hebben ergens).

[TeeDee]

Ugh, dat is toch wel een goede opzich: Bestaat het ID = 1 wel in je databank?

[gorgi_19]

Janoz schreef op maandag 05 juni 2006 @ 21:53:
[...]

Nope, bij een geconcatteneerde string weet de db laag niet wat variabel is en wat vast. Zodra je bv id=1 veranderd in id=2 heb je een andere query. Bij parametrized queries krijgt de db een query en een set parameters. De query is in dat geval altijd hetzelfde en alleen de parameters verschillen.

quote: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Even better: it will parametrize queries which don't even have parameters to keep the execution plan in the cache!

Dat valt dus wel mee

[Verwijderd]

Cyphax schreef op dinsdag 06 juni 2006 @ 10:24:
[...]

Evengoed is dat niet de reden dat het nu fout gaat en daar gaat het nu even om. Zullen we even niet teveel afdwalen?

Door dat afdwalen heb ik wel meer van SQL icm APS.NET geleerd

Het is intussen al opgelost, de code die ik hierboven geplaatst heb werkt gewoon goed, er staat alleen ergens anders in de pagina nog een stukje code die ruzie maakt waardoor hij niet goed naar de database kon schrijven... het is inmiddels dus opgelost