rs.Addnew vs SQL ="INSERT

Någon OBJdbConnection hittar jag inte. Har inte gått igenom koden så minutiöst. Men jag rekommenderar att du gör över till INSERT INTO.

Lycka till!

Det ser väl bra ut...
undrar också när man ska använda Add och när man ska använda Inset.

OBJdbConnection är namnet på min komunikation till databasen och finns som include på varje asp sida jag skriver.... därför behöver jag bara anropa den på det sättet....

Jag är väl också lite nyfiken på om jag ska open eller vad jag ska ha... och vad gör:
rs.Open SQL, OBJdbConnection, 3, 3 ?

ska jag skriva
rs.Execute SQL, OBJdbConnection,,128 ?

rs.Open SQL, OBJdbConnection, 3, 3 ?
kör jag med. =)

Hur gör man?

SQL ="INSERT INTO tabell (fält1, fält2, fält3) " & _
" VALUES('" & Request.Form("Värde1") & "', '" & Request.Form("Värde2") & "', '" & Request.Form("Värde3") & "')"

Japp, precis så. Sen kör du

Set rs = OBJdbConnection.Execute(SQL)

Och denna rad : Set rs = Server.CreateObject("ADODB.Recordset")

Behövs inte längre

Set rs = OBJdbConnection.Execute(SQL)

Eftersom SQL innehåller en insert så skall man inte skapa något recordset.

OBJdbConnection.Execute SQL,,128

men men.. vid update och delete då ?

LarsG skrev:

Eftersom SQL innehåller en insert så skall man inte skapa något recordset

Satt och somnade till lite där tror jag. Kollade i hans kod och såg att han använder ett recordset som hette rs. Sen tryckte jag in det Men det är tur att du rättar LarsG. Ska försöka vara lite mer noggrann.

Förresten. Har du lust att förklara det där med ,,128? Och länka inte till någon sida på MSDN man inte fattar ett skit av är du snäll

Jag förstår inte vad som är svårt med MSDN. Det är där jag har lärt mig det jag kan.

128 innebär att ADO inte skapar något recordset. Om man inte anger det så skapas ett tomt och stängt recordset när man gör execute på kommandon som inte returnerar någon post.

Nej jag har samma problem, jag kan inte tillräckligt mycket av ASP/VB och Access för att ha någon nytta av MSDN Jag läser alla LarsG's länkar dit men förstår ingenting, däremot håller jag inte med dig Ekström. Det är nyttigt för alla som kan lite mer än oss säkert, och för övrigt går jag kontinuerligt igenom alla mina gamla poster för att se om där är något jag kan ha nytta av.

I ett senare skede kan det vara bra med de där länkarna som referens.... när man kan lite mer

Men sedan håller jag ändå med Ekström har du tid och lust är en förklaring bättre än en länk till något man inte försår, gärna både länk och förklaring om du har tid och lust

tack på förhand

JAg tror faktiskt jag hajjar nu.... ? Om man ska göra

Set rs = Server.CreateObject("ADODB.Recordset")
SQL ="SELECT * FROM tabell"
[b]rs.Open SQL, OBJdbConnection, 3, 3[/b]
rs.Addnew
rs("fält") = Request.Form("form")
rs("fält2") = Request.Form("form2")

Medans om man gör en SQL = "INSERT så behöver man inte skapa något sådant recordset eftersom du kör det med en SQL fråga istället

Samma med select då? Om du gör en select och skriver alla <%=rs("fält") så behövs ett recordset ?

Rätta mig om jag har fel

Om du gör en select och skriver alla <%=rs("fält") så behövs ett recordset ?

...Japp

Här snackar jag lite för att använda ADO-uppdatering istället för INSERT. Fördelarna med det.

http://www.webforum.nu/showthread.php?s=&threadid=12576

ehe, men jag fattade inte mer av den tråden än att det finns något som kallas stored prcedures som vore det absolut bästa att använda....

Stored Procedures är bra prestandamässigt och så, men verktyget suger och det går inte att kategorisera på något vettigt sätt. Blir lite kluddigt när man har en stored-procedure för varje nersparning i databasen.

mrBlonde berättade för mig att på sitt gamla jobb hade de stored-procedures för att söka bland stored-procedures bara för att de hade så många...

oh my god! Tror jag håller mig till SQL