Mycket snack om att man ska använda INSERT/UPDATE, därför tänkte jag dra upp det så man kan diskuttera det.
Fördelar med ADO:
Jag brukar använda samma funktion för att lägga till post och redigera post. Istället för att då ha en If sats och två SQLer så är det smidigare att göra ungefär så här:
sql = "SELECT * FROM tblFoo WHERE iFooId = " & lFooId
Set rs = GetRecordset(sql)
If rs.EOF Then rs.AddNew
'Lägga in lite prylar
SaveRecordset rs
Då skickar man in id:t på posten som man vill redigera och vill man lägga in en ny så skickar man in -1.
Sen så är det enklare att loopa in saker. Exempel:
For Each f In rs.Fields
If dic.Exists(f.Name) Then
rs(f.Name) = dic(f.Name)
End If
Next 'f
Så enkelt loopar jag in saker när jag lägger in det. Det hade varit lite krångligare att loopa ut en INSERT/UPDATE sträng.
Sen en annan bra sak är att man slipper problem med '.
Fördelar med INSERT/UPDATE:
Prestanda! (kan nog finnas fler och då får ni fylla på mer här )
Jag tycker i alla fall att det är lämpligt att använda ADO på de ställena där man inte lägger till saker i databasen hela tiden. Som t.ex. räknare. Där bör man använda INSERT...
SQL är ett språk, ADO är en sammling objekt, så det blir svårt att jämföra...
Med "ren" SQL har du full kontroll på vad du håller på med, du vet datatyper, du konvertera och listan är lång på vad du kan göra. Genom att använda ett RecordSet (ett av de objekten i ADO) för att lägga till data drar ned fint på prestandan (om man nu bryr sig), genom att du först frågar efter data och sedan lägger till, istället för att bara lägga till. Oavsätt hur du gör så måste du lära dig SQL, men använder du dig av SQL dagligen så kommer du snart förstå varför det är kraftfullare att använda ett språk istället för att begränsa sig till en sammling metoder till ett objekt.
Men visst, till vissa funktioner måste man använda RecordSet och i andra fall måste man använda SQL. Men får jag valet att välja så blir det utan tvekan SQL.
Jag brukar använda samma funktion för att lägga till post och redigera post.
Jag menar att går att göra så, men det är inte rätt.
Visst det är lättsammt att koda så, men ur prestandasynpunkt så är det vansinne att hämta post(er) bara för att lägga till en. Jag hade gladeligen lagt till en if-sats för att få det rätt, men så är det ju bara jag...
Nja, jag var lite otydlig, det är väl inte själva hämtningen som är prestandasnattaren, utan själva sökningen.
Missförstå mig rätt här, jag tycker att RecordSet (som är skapat av objektet och inte av Connection) är ett mycket bra objekt som jag absolut inte skulle klarat mig utan i mitt jobb, men att använda det för att lägga till/uppdatera data gör jag bara då jag måste, vilket inte är ofta.
Skulle jag använda INSERT så hade jag så fort jag velat ha ett nytt fält man ska lägga in saker i så hade jag blivit tvungen att gå in i COM-objektet och skriva i SQLen och kompilera, ladda upp och installera o.s.v.
Med ADO lägger jag bara in ett inputfält i formuläret med samma namn som databasfältet.
Jo, den söker igenom alla poster i tabellen och kolla efter en match på i detta fall -1 och eftersom det inte finns något sådan värde i den kolumnen så returneras sedan ett tomt recordset, vilket tar en hel del prestanda när det börjar vankas upp emot ett antal tusen poster.
Nä, ren SQL e bättre, fast, ibland kommer man inte undan och de gångerna är väldigt, väldigt få.
nja, att hårdkoda ett sql-uttryck i ett com-object skulle jag nog inte göra.
Skulle antingen "passa" in sql-frågan som ska användas eller specifiera vilken SP som skulle användas.
SP ändrar man ju enkelt i SQL-Servern.
Om jag nu någon gång skulle skriva en ASP-applikation så skulle jag använda stored procedures, så slipper man hela hanteringen med att bygga frågor dynamiskt.