Lagra procedur?

[.sun]

Har pysslat en del med SQL, men aldrig trängt in på djupet. Lagrade procedurer har jag hört talas om, ett sätt att snabba upp saker som man gör ofta.

 

Frågor:

1. Kan jag skapa en lagrad procedur via ASP? Isf, hur?

2. Om inte, kan jag göra en via Access och sen anropa den från ASP?

3. Vad vinner jag på att göra en lagrad procedur som hämtar 100 poster från två tabeller, gentemot att låta en statisk ASP-sida göra samma sak med ADODB.Recordset och vanlig SELECT-sats?

[Mr Andersson]

Du kan inte använda SP öht i Access.

 

 

 

[FiEnD]

Hej, jag må inte vara expert, men jag kanske kan svara ändå.

 

En lagrad procedur läggs upp i cachen på SQLservern och då kan den snabbare ta fram resultatet åt dig än att köra en traditionell fråga via ASPn.

 

Lägg så många frågor som möjligt i Stored procedures.

 

Däremot så tror jag inte att du kan skapa SPs i Access?

 

Du kan skapa en procedur i ASP, men gör det hellre via Query Analysern

 

Mvh Fredrik

 

[Lars Berg]

Jo, det finns procedurer i Access. Begränsade i och för sig men det finns. Däremot så finns det ingen anledning att använda dom därför att det är mycket långsammare att använda än direkta sql-satser.

 

[Magnus Ahlkvist]

Är du säker på det?

Även Access använder sig ju av någon slags query-plan för att köra queries, och jag trodde att planen lagrades tillsammans med frågan i Access.

 

--

En röst talade till mig och sade:

”Le och var glad, ty det kunde vara värre”.

Så jag log, och jag var glad.

Och det blev värre.

 

[.sun]

Nehe? Varför finns det då en knapp i Access som heter Lagrade procedurer, och en som heter Skapa en lagrad procedur?

 

[.sun]

Ok, det går alltså att skapa en lagrad procedur i Access - men hur skriver man? Hjälpen i Access är inte särskilt ingående på den punkten om man säger så.

 

Jag har följande SELECT-sats, hur konvertera till procedur?

 

SELECT TOP 100 name, score FROM USERS u, HIGHSCORE h WHERE u.user_id = h.user_id ORDER BY score DESC

 

[Lars Berg]

Jag har sett ett antal tester som har jämfört direkta sql-satser och lagrade frågor i Access och alla visar att lagrade frågor är långsammare. Exakt varför vet jag inte men det verkar som om det blir en kompilering av frågan i alla fall.

 

[Magnus Ahlkvist]

Vilken version?

Är det Access eller ett Access-projekt som kopplar upp mot en SQL Server?

 

--

En röst talade till mig och sade:

”Le och var glad, ty det kunde vara värre”.

Så jag log, och jag var glad.

Och det blev värre.

 

[.sun]

I väntan på svar har jag funnit en del själv - proceduren är skapad i Access och funkar därifrån som den ska. Har hittat info om hur man gör i ASP, men det funkar inte. Jag har gjort följande:

 

Set oCmd = Server.CreateObject("ADODB.Command")

oCmd.ActiveConnection = cs

oCmd.CommandType = adCmdStoredProc

oCmd.CommandText = "highscore"

 

(min procedur heter highscore)

 

Får dock felmeddelandet "Odefinierad variabel: 'adCmdStoredProc'"

 

Skippar jag Option Explicit säger den:

"Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another."

 

Que?

 

 

[.sun]

Access 2000, och ja - jag har kopplat mig mot en SQL Server (2000 tror jag).

 

[Magnus Ahlkvist]

Aha, då är det alltså inte I Access utan bara via (som du skrev ser jag när jag tittar efter).

Dock är det lite ont om info i det du skriver, varför det har tagit ett tag att konstatera att det är SQL Server du använder.

Ok - ja, du kommer att tjäna en del på att använda en lagrad procedur istället för att använda dynamisk SQL.

Anledningen är att varje gång en query körs skapas en query-plan. Har en likadan fråga redan körts används en befintlig plan. Denna kompileras och körs. Använder du en lagrad procedur kommer planen att kompileras och den kompilerade varianten att användas när du kör den istället för att kompileringen sker innan SQL Server börjar arbeta med frågan.

 

För att anropa en lagrad procedur från ASP gör du ungefär likadant som när du använder dynamisk SQL.

 

Ex:

Proceduren:

CREATE PROCEDURE hund(
@apID int
)
AS
SELECT 
a.Namn,h.* 
FROM 
apa a 
INNER JOIN hund h ON h.apID=a.apID
WHERE a.apID=@apID

 

För att anropa från ASP:

dim conn
set conn=Server.CreateObject("adodb.Connection")
conn.Open "dsn=myDSN"
dim RS
set rs=server.createObject("adodb.Recordset")
rs.Open "hund " & request("apID"),conn

 

--

En röst talade till mig och sade:

”Le och var glad, ty det kunde vara värre”.

Så jag log, och jag var glad.

Och det blev värre.

 

[.sun]

Hej vad det går undan!

 

Hade inte inkluderat definitionen av adCmdStoredProc, men det gick ju att byta ut mot 4. Nu funkar det! (Fan vet dock om det går snabbare...)

 

Tack ni som engagerat er i frågan. Jag kan slå fast att det går alldeles utmärkt att göra en procedur i Access, och tror tom att det går att göra i ASP - skapa ett ADODB.Command, sätt CommandText till "CREATE PROC..." och kör Execute. Klart?

 

[.sun]

Dock är det lite ont om info i det du skriver

 

Sorry om jag vart lite kortfattad.

 

set rs=server.createObject("adodb.Recordset")

rs.Open "hund " & request("apID"),conn

 

Menar du att jag inte behöver gå omvägen via ADODB.Command?

 

[Magnus Ahlkvist]

Yep, det behövs inte. Dock ger adodb.Command lite större möjligheter om du har optional-parametrar i proceduren. Du kan namnge parametrar och lägga till dem innan du gör execute på proceduren.

Dessutom hanterar commandobjektets parametrar "förbjudna" tecken i SQL åt dig (ex.vis ')

 

--

En röst talade till mig och sade:

”Le och var glad, ty det kunde vara värre”.

Så jag log, och jag var glad.

Och det blev värre.

 

[Magnus Ahlkvist]

Alternativt göra:

conn.execute "CREATE PROC..."

 

Behöver man inte ett command-objekt eller ett recordsetobjekt så kan man lika gärna köra direkt ifrån ett connection-objekt.

 

Detsamma gäller för övrigt för mitt tips innan. Man behöver inte göra server.createobject("adodb.recordset"), det går lika bra att göra

set rs=conn.execute("hund " & request("apID"))

 

--

En röst talade till mig och sade:

”Le och var glad, ty det kunde vara värre”.

Så jag log, och jag var glad.

Och det blev värre.