---

Hej NG

Jeg arbejder med SP og MSSQL 7 og sidder og tænker over, de her mange
muligheder for at kalde en SP fra ASP sider....
Er der nogen der har en tommelfinger regel for eller en metode for hvilken
måde man kan/skal bruge??

Jeg leger i dag med disse tre "kald" modeller, og syntes ikke jeg kan mærke
den store forskel, men er den ene bedre end den anden eller finde der en
bedre måde, eller er det "hips som haps"??

Test er en SP
Som forventer to parametre, @CustomerID og @CategoryID, som sende via
session("SQLstr")....

Model 1:
Dim oRS, oConn
Set oRS = Server.CreateObject("ADODB.RecordSet")
oRs.CursorLocation = adUseClient
oRS.Open "Test " & Session("SQLstr"), oConn, adOpenForwardOnly,
adLockReadOnly

Model 2:
Dim cmd_select, oRs, oConn
Set cmd = Server.CreateObject("ADODB.Command")
With cmd_select
.ActiveConnection = oConn
.CommandType = adCmdText
.CommandText = "{CALL Test " & Session("SQLstr") & "}"
.CommandTimeout = 30
End With

Set oRs = Server.CreateObject("ADODB.Recordset")
oRs.CursorLocation = adUseClient
oRs.Open cmd_select


Model 3:
Dim cmd_select, oRs, oConn
Set cmd_select = Server.CreateObject("ADODB.Command")
With cmd_select
.ActiveConnection = oConn
.CommandType = adCmdStoredProc
.CommandText = "Test"
.CommandTimeout = 30
.Parameters.Append .CreateParameter("@CustomerID", adInteger,
adParamInput, 0, Session("CustomerID"))
.Parameters.Append .CreateParameter("@CategoryID", adInteger,
adParamInput, 0, Session("Category"))
.Execute, , adExecuteNoRecords
end with

Set oRs = Server.CreateObject("ADODB.Recordset")
Set oRs = cmd_select.Execute

Er der nogen der kan hjælpe mig med at vælge den bedste af de tre? Eller
vise mig en fjerde, femte..... bedre metode at gøre det på?

På forhånd tak

Oz

---

Hej,

Der er flere forskellige måder at gøre det på - afhængigt at hvad du skal
bruge dit resultatsæt til og hvordan.

Den nemmeste - og mest brugte - er dog nok:

set Conn = Server.Createobject("ADODB.Connection")
Conn.Open "DSN=endsn;UID=brugernavn;PWD=password"
Set RS = Conn.Execute("sp_enstoredprocedure '" & username & "','" & password
& "'"
Do While Not RS.eof
' Gør noget her
RS.MoveNext
Loop
Set RS = Nothing
Conn.Close
Set Conn = Nothing

Du kan altså bare kalde din stored procedure direkte i din querystring
sammen med parametre og det hele.

Hilsner,

Tony

"oz" <gonzo@strike-team.com> wrote in message
news:9vv5ag$9os$1@sunsite.dk...
> Hej NG
>
> Jeg arbejder med SP og MSSQL 7 og sidder og tænker over, de her mange
> muligheder for at kalde en SP fra ASP sider....
> Er der nogen der har en tommelfinger regel for eller en metode for hvilken
> måde man kan/skal bruge??
>
> Jeg leger i dag med disse tre "kald" modeller, og syntes ikke jeg kan
mærke
> den store forskel, men er den ene bedre end den anden eller finde der en
> bedre måde, eller er det "hips som haps"??
>
> Test er en SP
> Som forventer to parametre, @CustomerID og @CategoryID, som sende via
> session("SQLstr")....
>
> Model 1:
> Dim oRS, oConn
> Set oRS = Server.CreateObject("ADODB.RecordSet")
> oRs.CursorLocation = adUseClient
> oRS.Open "Test " & Session("SQLstr"), oConn, adOpenForwardOnly,
> adLockReadOnly
>
> Model 2:
> Dim cmd_select, oRs, oConn
> Set cmd = Server.CreateObject("ADODB.Command")
> With cmd_select
> .ActiveConnection = oConn
> .CommandType = adCmdText
> .CommandText = "{CALL Test " & Session("SQLstr") & "}"
> .CommandTimeout = 30
> End With
>
> Set oRs = Server.CreateObject("ADODB.Recordset")
> oRs.CursorLocation = adUseClient
> oRs.Open cmd_select
>
>
> Model 3:
> Dim cmd_select, oRs, oConn
> Set cmd_select = Server.CreateObject("ADODB.Command")
> With cmd_select
> .ActiveConnection = oConn
> .CommandType = adCmdStoredProc
> .CommandText = "Test"
> .CommandTimeout = 30
> .Parameters.Append .CreateParameter("@CustomerID", adInteger,
> adParamInput, 0, Session("CustomerID"))
> .Parameters.Append .CreateParameter("@CategoryID", adInteger,
> adParamInput, 0, Session("Category"))
> .Execute, , adExecuteNoRecords
> end with
>
> Set oRs = Server.CreateObject("ADODB.Recordset")
> Set oRs = cmd_select.Execute
>
> Er der nogen der kan hjælpe mig med at vælge den bedste af de tre? Eller
> vise mig en fjerde, femte..... bedre metode at gøre det på?
>
> På forhånd tak
>
> Oz
>
>

---

"Tony Lorentzen" <tony@lorentzen.com> wrote in message
news:a0adot$g53$1@news.cybercity.dk...
> Der er flere forskellige måder at gøre det på - afhængigt at hvad du skal
> bruge dit resultatsæt til og hvordan.
>
> Den nemmeste - og mest brugte - er dog nok:
>
> set Conn = Server.Createobject("ADODB.Connection")
> Conn.Open "DSN=endsn;UID=brugernavn;PWD=password"
> Set RS = Conn.Execute("sp_enstoredprocedure '" & username & "','" &
password

Det skal dog siges at det er bedre rent performance mæssigt at bruge command
objektet hvis man undgår at bruge adovbs.inc. Men det er lidt mere
besværligt da alle parametre skal defineres såvel input som output.

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:a0apv2$14a2$1@news.cybercity.dk...
> Det skal dog siges at det er bedre rent performance mæssigt at bruge
command
> objektet hvis man undgår at bruge adovbs.inc. Men det er lidt mere
> besværligt da alle parametre skal defineres såvel input som output.

Det har du fuldstændig ret i - men jeg tror nu ikke at det betyder noget før
du virkelig har meget trafik på dit site. Der findes nogle performance tests
derude - desværre har jeg ikke lige links liggende - men mon ikke en søgning
på Google kan hjælpe?

Tony Lorentzen
tony@lorentzen.com

---

"Tony Lorentzen" <tony@lorentzen.com> wrote in message
news:a0dpu6$2tof$1@news.cybercity.dk...
> Det har du fuldstændig ret i - men jeg tror nu ikke at det betyder noget
før
> du virkelig har meget trafik på dit site. Der findes nogle performance
tests
> derude - desværre har jeg ikke lige links liggende - men mon ikke en
søgning
> på Google kan hjælpe?

"Scalability will never be a problem if you do not expect success"

--
Jakob Andersen

---

"Jakob Andersen" <jakob@effectus.dk> wrote in message
news:a0dqe4$2uk4$1@news.cybercity.dk...
> "Tony Lorentzen" <tony@lorentzen.com> wrote in message
> news:a0dpu6$2tof$1@news.cybercity.dk...
> > Det har du fuldstændig ret i - men jeg tror nu ikke at det betyder noget
> før
> > du virkelig har meget trafik på dit site. Der findes nogle performance
> tests
> > derude - desværre har jeg ikke lige links liggende - men mon ikke en
> søgning
> > på Google kan hjælpe?
>
> "Scalability will never be a problem if you do not expect success"

Hehe - jeg forstår godt hvad du mener. Men mine kunder vil nok ikke kunne
forstå hvis jeg sender dem en regning på dobbelt så meget som mine
konkurrenter fordi jeg hver evig eneste gang skal lave den store forkromede
løsning med load-balancing og performance-tests ud i ekstremerne. Hvis man
ved hvad man laver og hvad man har med at gøre (dvs. hvis man ved hvordan
man koder ordentligt) kan man sagtens lave et site der performer ret godt
fra starten af - uden de store kvaler. Det største performanceproblem jeg
har oplevet har som regel været at kunden ligger på et webhotel sammen med
500 andre kunder hos en skod-udbyder med en dårlig opkobling og lav teknisk
know-how.

Det er klart nok en balance mellem pris, kvalitet. Og der er stor forskel på
at bygge et system beregnet til at servicere 1000 samtidige brugere og at
lave et site som får 2 hits i minuttet.

Tony

---

"Tony Lorentzen" <tony@lorentzen.com> skrev

> Hehe - jeg forstår godt hvad du mener. Men mine kunder vil nok ikke kunne
> forstå hvis jeg sender dem en regning på dobbelt så meget som mine
> konkurrenter fordi jeg hver evig eneste gang skal lave den store
forkromede
> løsning med load-balancing og performance-tests ud i ekstremerne. Hvis man
> ved hvad man laver og hvad man har med at gøre (dvs. hvis man ved hvordan
> man koder ordentligt) kan man sagtens lave et site der performer ret godt
> fra starten af - uden de store kvaler. Det største performanceproblem jeg
> har oplevet har som regel været at kunden ligger på et webhotel sammen med
> 500 andre kunder hos en skod-udbyder med en dårlig opkobling og lav
teknisk
> know-how.
>
> Det er klart nok en balance mellem pris, kvalitet. Og der er stor forskel
på
> at bygge et system beregnet til at servicere 1000 samtidige brugere og at
> lave et site som får 2 hits i minuttet.


Tak for jeres indlæg, jeg er lige kommet hjem fra ferie, så derfor min sene
response.

Jeg kan godt tilslutte mig snakken om "balance mellem pris, kvalitet", men
da det drejer sig om min egen site så går jeg efter kvalitet og stabilitet
og holder mig nok til Command metoden, selvom jeg syntes det ofte er nemmere
med Recordset metoden...

Tak igen

Oz