hej!

Jag använder datasets som databärare mellan lagren i min app. Men, jag skickar aldrig tillbaka dataseteten med uppdaterade poster utan använder dem bara för att visa data i griddar o.s.v. När data skall uppdateras skapar jag sql-satser som insertas/uppdaterar. Så datasetet används bara för att visa data. Vore det inte bättre att använda någon annan databärare genom applikationens lager som tar lite mindre minne i anspråk, äv dat dataset gör? Någon som vet?

mvh
Hubbe

Du kan använda en DataReader istället. Fördelen är att den inte tar upp lika mycket kraft. Det finns dock en nackdel och det är att den håller kopplingen till databasen öppen. Så man bör hämta data, göra vad man ska, och sen stänga readern så snabbt man kan.
Själv så använder jag inte datasets utan klassobjekt, men jag vet att det finns mycket man kan göra med ett dataset. Men om man som i ditt fall inte använder sig av datasettets inbyggda funktioner så är en DataReader bättre.

Men att hålla connections mot databasen öppen låter inte så bra. Frågan är hur mycket minne jag sparar på att använda datareader i så fall? Applikationen använder en Access-databas och ansluter med OLEDB. Som det är nu stänger jag alla connections redan i data access lagret direkt efter jag hämtat ut mitt dataset.

Jo, det är som sagt nackdelen och det blir kanske ytterligare nackdel i och med att du kör Access.
Men gör ett par tester och prova om det blir någon skillnad. En DataReader är så pass mycket lättare än ett DataSet att det kanske lönar sig ändå. Mycket beror på datamängden hur länge readern behöver vara öppen.

Om du inte behöver informationen för en längre tid, t.ex mer än att databinda till griddar mm, så hade jag gått på Patriks linje med att använda en <b>DataReader</b>. Sen läste jag en sak som oroar mig lite.

<b>När data skall uppdateras skapar jag sql-satser som insertas/uppdaterar</b>

Jag tolkar detta som att du bygger ihop en SQL sträng som du sedan exekverar, stämmer detta? Om detta är fallet så rekommonderar jag sig att använda <b>Parameters</b> på ditt <b>OleDbCommand</b> objekt. Där stoppar du in <b>OleDbParameter</b> som anger parametarna du behöver, samt vilken typ (och evt storlek) du använder. Detta skyddar mot något som heter SQL-injection.

Du kan enkelt hitta mer om SQL-injection genom att göra en sökning på google. Jag hinner inte leta fram ett par länkar ut min lista just nu. Hittar du inget så hojta till så fixar vi det ikväll när jag inte sitter på jobb.

Ja, jag bygger ihop sql-strängar och exekverar dem med följande vb.net kod:

objExecute = New OleDb.OleDbCommand(strSQL, myConnection)
strErrText = CStr(objExecute.ExecuteNonQuery())

Det är väl så du menar, med sql-satsen som parameter till command-objekt?

/Hubbe

Nope, det är inte det han menar :)

Det han menar är något i stil med detta (kommer inte ihåg syntaxen, har körs dataobjects.net ett tag nu, har lite annan syntax för det här, men det är samma stil på det hela. Du hittar vad klasserna heter, exakt vad metoderna heter etc. i msdn. Det viktiga här är att du kan <b>principen</b>! ;) )

<code>
xCommand c;
c = new xCommand(min_anslutning);
c.CommandText = "insert into min_tabell(första_texten, andra_texten) values(%param1, %param2)";
c.Parameters.Add("param1", min_text_ruta_med_livsfarlig_text.Text);
c.Parameters.Add("apa3", "HEJ!' % \\ //");
c.ExecuteNonQuery();
</code>

Som du ser stoppar du bara in parametrarna i sql-frågan, värdena på parametrarna stoppas in i efterhand. All escapning å justering sköts automagiskt och det är helt säkert! Notera att det <b>inte</b> finns några extra '' runt parametrarna, det sköts också helt automagiskt! :)

Om du alltid ser till att använda det här sättet så behöver du inte ha problem med sk. sql injections, konstiga buggar etc.

Ok, då är jag med. Skall prova detta! Tack allihopa.

mvh
Hubbe

Hubert,

I korta drag är SQL-injection när en användare lyckas mata in SQL kod som körs. Om du t.ex har en textruta och inte använder SQL parameter och/eller validerar innehållet i textboxen innan du sparar ner det så kan man t.ex skriva in

<info>
Hej ' drop table users --
</info>

så skulle det först köra ditt query med <b>Hej</b> som värde, sen sql uttrycket <b>drop table users --</b> vilket skulle kunna få förrödande konsekvenser. Med hjälp av SQL injection kan man göra <b>MYCKET</b>. En väldigt bra och enkel introduktion är http://www.nextgenss.com/papers/advanced_sql_injection.pdf ta även en titt på http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf

Faktum är att jag har gjort klientsides JavaScript som kollar om användaren matat in DELETE INSERT UPDATE ALTER DROP o.s.v i textfälten. Om någon gör det blir det aja baja, kan man säga.. borde inte det räcka för att stoppa dessa fasoner?

/Hubbe

Nix. Javascript kan man kringgå hur enkelt som helst. Vad hindrar mig från att skriva en egen html fil på min dator med ett formulär som har din action satt till din sida? Vips sp ha rjag kringgått ditt skydd. Parameters gör så mycket mer. Den kontrollerar inte bara datatypen, den kontrollerar även t.ex längden. Desutom är det väldigt svårt att förutse alla saker som kan matas in. Du skall alltid bygga efter principen att all information som når din kod är elak tills motsatsen har bevisats genom att t.ex validera den med regular expressions och kör den igemom ett paramtriserat anrop.

ahh kan de va så jävliga!? Ok, då får det bli parametrar på command-objektet. Tack!

/Hubbe

Hanteringen av inmatning (i webbappl) BÖR vara:
<info>
1. Eventuellt Javascript för att ge användaren hjälp. (jag rekommenderar det)
2. Alltid Datavlidering mot affärsregler (systemets regelverk) i objekt.
3. Alltid Commandobjekt med parametrar,
mot hacking, och för att få korrekt parametersättning, inkl snyggare kod.
Alltså släng ut "SELECT " & a & "," & b & "," ....
Det ser förfärligt ut, IMHO =)
</info>