och varför envisas folk med att skapa ett recordset för att stoppa IN saker i databasen?
det går alldeles lysande att göra det där på RÄTT sätt, dvs med en SQL insert
strSQL="INSERT INTO [order](dinafält) VALUES(Dinavärden)"
Connect.Execute(strSQL)
och varför envisas folk med att skapa ett recordset för att stoppa IN saker i databasen?
det går alldeles lysande att göra det där på RÄTT sätt, dvs med en SQL insert
ADO är egentligen ett ganska avancerat objektorienterat gränssnitt för databaser.
Tanken är att man ska använda metoder som t.ex. AddNew för att koden ska bli oberoende av databastyp.
Jag är inte helt säker, men AddNew fixar även SQL-injections och är således säkrare.
Man slipper alltså pilla med strängar för att bygga egna SQL-frågor, men allt är en smaksak. :)
ja, ADO är egentligen ganska komplext, men i 9 fall av 10 så använder folk den här metoden enbart för att de kopierat/kollat på gamla exempel från tex aspsidan /idg:s webskola.
Med andra ord så använder de inte de mer avancerade funktionerna i ADO
ett tydligt bevis på detta är användandet av variabeln "addera" för att lagra sql-strängar ;)
ja, ADO är egentligen ganska komplext, men i 9 fall av 10 så använder folk den här metoden enbart för att de kopierat/kollat på gamla exempel från tex aspsidan /idg:s webskola.
Med andra ord så använder de inte de mer avancerade funktionerna i ADO
ett tydligt bevis på detta är användandet av variabeln "addera" för att lagra sql-strängar ;)
Ja, "addera" känner vi igen sedan IDG-tiden.
Däremot måste jag nog hålla med de andra om det här med input i databasen via .Addnew; det är ett bra sätt i många fall, vid t.ex. datatypshantering, dynamiska antal inputs (iterering till input) eller för överskådlighet. Prestanda däremot blir ju lite lidande.
Men rent generellt håller jag också med att man skall använda direkta SQL-frågor om man kan vid input.
296 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e