Jag bara undrar vilken av dessa metoder är den optimala för att hämta data - disconnected recordset eller getrows. En jag känner sa att det första är det optimalaste är det så?

Det beror helt på vad du ska göra, ibland är servsided det bästa sättet, det är situationen som styr...

Vad innebär serverside?

Det jag vill göra är att jag loppar ut inlägg från ett forum. Tabellen innehåller kring 10000 inlägg. Idag använder jag getrow. Skulle siten optimeras om jag använde disconnected recordset?

Jag tror du skulle tjäna på att använda serversided recordsets (rätta mig ADO-experter) dvs clientside = adouseserver

Om man vill ha en "FireHose" metod för att skriva ut data från en databas (alltså snabbt skriva ut, inte skriva tillbaka till databasen) så ska man använda cursorlocation = clientside och cursortype = forwardonly.

GetRows innebär ju att man arbetar med en array, och det är också snabbt men det blir jobbigt att underhålla och förstå koden

jmfr response.write vData(3,4) och response.write rs("customer_id")

Eller hur?

Cursorlocation serverside (adUseServer), innebär att recordsetet inte blir disconnected och du håller en connection uppe mot databasen längre än du kanske behöver.

/Martin

Jag som trodde att jag hade lite koll men detta har jag ingen koll på alls känner jag... :)

Du kan inte exemplifiera vad det innebär kodmässigt? Jag har inte tillgång till servern så att jag kan installera VB-komponenter på den men det är väl inte det du syftar på antar jag.

Ok...jag tror jag förstår. Men är det inte så att ju längre man har databasen öppen desto mer prestanda tar det. I så fall borde ju serverside ta mer kräm än vad getrows gör. Jag får inte ihop det känner jag.

Just idag kör jag också access... :( och har cirka 9 inne samtidigt och detta kommer nog öka. Men jag försöker uppdatera upp till mysql snarast... :)

hej igen!

Här är lite länkar till liknande diskussioner...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adosql/adoprg02_4ui7.asp


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbpj99/html/ds0599.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev99/html/VB99E1.asp

/Martin

Clientside är oftast snabbare, speciellt om du har databasen på en annan maskin än den din kod körs på.

Jag röstar på clientside!

IMHO vet jag inte om jag tycker att det är lika självklart. Om det är en stor datamängd det handlar om så måste det ju överföras till klienten, det ställer krav på bandbredd. Då kan det ju vara bättre att skicka bara det bearbetade datat till klienten.

Sedan tycker jag nog inte heller att att getRows är svårt att förstå och underhålla. Använda konstanter istället för heltal är ju ett tips för att hålla bättre koll typ vData(i,USER_ID).

Som alltid så beror det ju på förutsättningar och vad som skall utföras. Ett diskussionsforum med mycket data, vill man ju helst slippa loopa igenom så mycket som möjligt och istället returnera datat i rätt ordning på en gång, då är antagligen en StoreProc med temptabeller att föredra, sedan har jag för mig att getRows är det snabbaste sättet att ta fram informationen.

Håller med dig om att det finns tillfällen då det ena passar bättre än det andra (det är väl antagligen därför det finns flera alternativ :)

Saker som bör övervägas vid val kan vara följande:
Databasen på annan maskin - serveside generar massor med nätverkstrafik - det blir långsammare (såvida det inte handlar om väldigt stora resultat som ska bearbetas. Trafiken generas när du t.ex kör .MoveNext då måste en cursor flyttas i sqlserver- testa med tracen)
Klustrade servrar - det enkelt att klustra webservrar - svårt att klustra databaser - flytta arbetet till webservern (alltså kör clientside)
Databashanterare - du kanske funderar på att flytta till en annan databashanterare (access-sqlserver-oracle)
Om du har många samtidiga användare - kortare databassessioner = färre connections = bättre prestanda (använd clientside)

Sen finns det säkert tusen situationer då serverside är att föredra...

/Martin

Jag ska titta lite och läsa lite på de länkar jag fick här också...