rs.open metoder...

Hade det inte varit lättare att bara göra så här?

Set objRS = connection.Execute(sql)

Du har parametrarna i fel ordning

objRS.open sql, connection, AdOpenForwardOnly,AdLockReadOnly, AdCmdText

om du använder de värdena så kan du lika gärna göra

set objRS = connection.execute(sql)

och ta bort

 set objRS = server.createobject("adodb.recordset")

Har använt mig av connection.execute tidigare... men nu försöker jag skriva prestanda mässigt bra kod.

Använder man connection.execute så har man under en kort tid två kopior av sitt RS i minnet... inte bra

set connection = Server.CreateObject("ADODB.connection")
set objRS = Server.CreateObject("ADODB.recordset")
connection.open ("odbc")
sql = "SELECT * FROM tblArticklar ORDER by id"
objRS.open sql, connection, AdOpenForwardOnly

arrayMedData = objRS.GetRows()

objRS.Close()
set objRS = nothing
connection.close
set connection = nothing

Som ni ser så kan jag här stänga min databaskoppling på en gång och dessutom har jag all data i en array som jag nu i lugn och ro kan använda mig av utan att behöva ha dåligt samvete för någon öppen databaskoppling...

...mitt problem är dock fortfarande som jag skriver i det första inlägget!!! (... ordningen ändrade inget!)

Du kan använda getrows och stänga ditt recordset oavsett om du använder

set rs = connection.execute

eller

set objRS = server.createobject("adodb.recordset")
objRS.open sql, connection, AdOpenForwardOnly,AdLockReadOnly, AdCmdText

om du använder connection.execute så slipper du dessutom ett anrop. Det finns ingen anledning att använda open.

Om du fortfarande får fel så är det beroende på att du inte definierar konstanterna AdCmdText etc.

"...inte definierar konstanterna AdCmdText ..." :?

Nä just det... hur gör man det?!

Det vanligast sättet är att inkludera adovbs.inc på din sida. Jag skulle dock rekommendera att du öppnar den filen och lyfter ut deklarationen av de konstanter du använder till din asp-sida, så blir det ganska bra.

Eller bara kontrollera vilka värden konstanterna motsvarar, och använd dem direkt istället. Titta alltså efter lite grann i adovbs.inc.

Mvh,

adovbs.inc... givetvis... tack @nders

Om du vill skriva effektiv kod är det inte bra att inkludera adovbs.inc utan då är det bättre att själv definera de konstanter man använder.

Använder man connection.execute så har man under en kort tid två kopior av sitt RS i minnet

Hur då?

@nders skrev:

...du öppnar den filen och lyfter ut deklarationen av de konstanter du använder till din asp-sida...

Jo, jag ser att han skrev det.

Jag är mer nyfiken på det här med två kopior av rs. Har du läst det någonstans och i så fall var?

DatorMagazin nummer 7 år 2001 tror jag. Det var på sidan 128 eller nått...

En artikel om asp-optimering. (MYCKET bra!!!)

Tidigare diskussion angående denna artikel:
http://cgi.webforum.nu/wf/Forum11/HTML/004779.html

För att återkomma till LarsG:s fråga tar jag mig tiden att citera eftersom det är en givande diskussion.

"Ett datalager är konstruerat för att hantera stora mänder data, relationer och så vidare. Därför bör all datahantering ske i datalagret. Något annat värt att tänka på, och detta gäller all programmering: Generellt kan sägas att allt som görs i bakgrunden är dåligt. En explicit algoritm som en programmerare själv har utformat är i nio fall av tio snabbare än när saker och ting sköts i bakgrunden.

Ett exempel är att endast skapa upp ett recordset-objekt för databasåtkomst. Det går naturligtvis att göra eftersom ADO kommer att skapa ett connection-objekt i bakgrunden, men prestanda är långt ifrån optimala. Låt mig för enkelhetens skull visa det absolut optimala sättet att skapa en koppling och ett recordset till en databas. Jag ska sedan redogöra för varför just detta är det optimala sättet.

set objconn = Server.CreateObject("ADOdb.Connection")
set objRS = Server.CreateObject("ADOdb.Recordset")
objConn.Open(strConn)
objRS.Open(strSQL, strConn, AdOpenForwardOnly, AdLockReadOnly, AdCmdText)

[...]lägg märke till att vi skickar den öppna databaskopplingen som argument till Openmetoden av Recordset-objektet. Fördelen med detta är att vi aldrig kommer att ha två kopior av recordsetet i minnet, vilket blir fallet om man använder sig av execute-metoden av connection-objektet. Eftersom executemetoden alltid reutrnerarett recordset och vi kopierar över det till recordset-objektet[...]

(Lindberg, Magnus, Datormagazin, 7-2001)

Jag skulle gärna se en prestandajämförelse.
I allt annat jag har läst om ADO så har jag inte sett detta. Tvärtom så har man alltid menat att open är onödigt.

Då vet du vad du ska göra ikväll LarsG

Vi ser fram emot att se reultatet

Det behöver nog LarsG inte göra .... har för mig att vi redan dragit diskussionen om ADO vs. CONN recordset med tidtagning med hjälp av Timer() i och för sig .... som sagt, bara att söka på forumet

.... och, har "för" mig att conn va det snabbaste alternativet .... fast .... om någon kan köra ett stress test med ett "ritktigt" verktyg för det och visa tider så vore det bra
cya,
PatrikB