sidan snabbare med dim och rs.movenext

rs.cursorlocation = 3 'adUseclient 
rs.open
'eller
set rs = connect.execute("select ...")
if not rs.eof then
   rows = rs.getrows() 'eller getstring
end if

I båda fallen så hamnar hela resultatet på klientsidan så du kan stänga din connection efteråt.

Det viktigaste är dock att man ställer sådana sql-frågor så att databashanteraren kan utnyttja index.

Lars G > Kan du förklara lite mer vad rs.cursorlocation = 3 gör. På vilket sätt hamnar det på "klientsidan"?

Vad menar du med att man ska ställa sådana sql-frågor så att databashanteraren kan utnyttja index.

:)

Man kan se det så här

Webklient ....... Webserver
------------ ........ ------------ ......... -----------
!browser!<---->!IIS/PWS!<----->! DBMS !
------------ ........ ------------ .......... -----------
........................ Databasklient ... Databasserver

(Finns det ingen pre-tag?)

Webservern är alltså klient till databasen. Databasen/servern behöver inte ligga på
samma maskin (om man bortser från access.) En sak som är betydelsefullt för prestanda
är hur många anrop man gör till databasen. Om man använder getrows /adUseClient så blir
det färre anrop.
Andra aspekter som är viktiga att föra över så lite data som möjligt. (Det är en av anledningarna till att man inte skall använda select *). T.ex, så ser man
alltför ofta lösningar som

sql = "select * from users"
set rs = server.createobject("adodb.recordset")
rs.open sql,connection
do until rs.eof
   if rs("username") = request.form("username") then
      rs("password") = request.form("password")
      rs.update
   end if
   rs.movenext
loop

dvs man flyttar alla poster från databasen till klienten. Nästa försök

sql = "select * from users where username = '" & request.form("username") & "'"
set rs = server.createobject("adodb.recordset")
rs.open sql,connection
if not rs.eof
   rs("password") = request.form("password")
   rs.update
end if

är ju mycket bättre men ändå inte helt optimalt då man flyttar onödigt mycket data.

om man gör

sql = "update users set password = '" & request.form("password") & "'" &_
" where  username = '" & request.form("username") & "'"
connect.execute sql,,128

så har man minimal dataöverföring mellan klient och server. Hantering av
recordset innebär en hel del extra anrop till databasen. Det behöver inte vara så kritiskt
om applikationen mestadels innehåller läsningar.

För att kunna göra effektiva sökningar i en databas så är index av största vikt. Om man inte har
gjort något speciellt med sin tabell och lägger till nya poster så kommer dessa (i de flesta
fall) att hamna i den ordning som dom läggs till, t.ex.

namn Stad
-------------
bertil X-löv
Lisa Ystad
adam Sundsvall
Sinead Dublin

Om man nu vill hämta en post där namn = 'adam' så måste databashanteraren läsa igenom alla poster.

För att snabba upp sökningen kan man då lägga till ett index på namn. Det innebär att
databashanteraren skapar en extra tabell som är sorterad med avseende på namn.

namn
----
adam
bertil
Lisa
Sinead

Då kan man göra en binärsökning i indextabellen, vilket är avsevärt mycket snabbare än att söka
sekventiellt. Indextabellen innehåller en referens till posten i den ursprungliga tabell så att
man kan hämta data. Det går att ha flera index på samma tabell, så man kan ha ett index på namn
och ett på stad. Det beror på vilka typer av sökningar man gör. Index är också relevanta när man
gör update och delete för de operationerna innebär ju att man gör en sökning först.

När man skapar en tabell så brukar man ange en primärnyckel, vilket också blir ett slags index.

Tack för ett fantastiskt bra svar Lars!

:bire

Men måste man ändra SQL-frågan då man använder ett index istället för att fråga "direkt på"?
Hur skapar man ett index i Access (eller går det bara med en primärnyckel)?

:)

Nej, hela vitsen är att man inte behöver ändra på sql-frågan om man lägger till eller tar bort index. Det är databashanterarern som avgör om man skall använda ett index för en viss sökning.

Det går nog att skapa ett index med access genom att välja i menyer och klicka och dona. (Det vet jag inget om.)

Det går att skapa index med hjälp av SQL

create index it on personer(namn)

t.ex.

man kan också ange att det bara får vara unika värden i de kolumner som indexet omfattar.

create unique index it on personer(namn)

Mycket fint inlägg, LarsG!

Närmast pre-tagg man kommer är kanske kod-taggarna?
aaa bbb ccc ddd
--- --- --- ---
1   2   3   4

(tror jag i alla fall)

Red: Det gick inte, tydligen. Är [perl] en gammal wF-tagg från UBB-tiden månne?

Mvh,