Har en SP som inte vill fungera. Den fungerar tills jag sätter Return framför, då vill den inte alls. Fungerar även om jag tar bort (Select * From db2 Where db2.Matarnr=db1.Matarnr). Den klagar på db1 att den inte skulle finnas, men det gör den.

<code>
CREATE PROCEDURE dbo.CountBort
(
@Lista Varchar(50)
)
As
Return(Select Count(id) From db1 Where Exists (Select * From db2 Where db2.Matarnr=db1.Matarnr) AND Lista=@Lista)
</code>

Hej!

Deklarera en int variabel.
Tilldela den värdet av select satsen.
Returnera variabeln.
EDIT: Såg nu att jag inte läst frågan ordentligt. Återkommer.
EDIT IGEN: Det jag skrev först borde fungera.

//Håkan

Nu är jag inte med på vad du försöker göra...

För en SP använder du inte RETURN, den skickar automatiskt tillbaka de recordset som du skapar om du inte anger NOCOUNT ON.

Om du däremot vill returnera data till olika variabler så deklarerar du dessa som vilken parameter som helst med tillägget OUTPUT och sätter dem till det värde du vill returnera.

Om du vill använda nyckelordet RETURN så skall du istället skapa en funktion och inte en sp.


Lycka till!

// Johan

Johan

Visst fungerar det med RETURN i SP.
T.ex. för att skicka ut felkoder, om något inte gick bra.
Förstår hur Hans tänker, det fungerar också att göra så.
Kanske mer renodlat som du skriver.....

//Håkan

De returnerade inte något värde utan return (asp.net).

Men jag löste det tack vare deklarationen. Denna funkar fint :)

<code>
CREATE PROCEDURE dbo.CountBort
(
@Lista Varchar(50)
)
As
Declare @CountBort int
Select @CountBort = (Select Count(id) From db1 Where Exists (Select * From db2 Where db2.Matarnr=db1.Matarnr) AND Lista=@Lista)
Return(@CountBort)
</code>

Hej Håkan,

Det går, som du helt riktigt skriver, att använda RETURN med SP, men det är inte från början tänkt att användas så. RETURN är tänkt att användas med funktioner. Därför finns det vissa varianter med SP och RETURN som kan krångla till det. Därav jag försökte förklara hur man kan göra för att det skall fungera "enligt konventionerna".

På samma sätt kan jag också få en funktion att returnera ett recordset även om den inte är tänkt att göra så. SQL ärganska flexibelt och man kan ofta göra saker som det inte var tänkt från början, vilket många gånger är bra eftersom man då inte hindras att lösa framtida problem som inte funnits med i tankarna då SQL språket designades... :-)

// Johan

Vad pratar du om? Procedurer har funnits i SQL Servers T-SQL betydligt längre än funktioner, och procedurer har alltid kunnat returnera ett värde med return. Det är inget fel alls i att göra så, det är ett utmärkt sätt att returnera ett heltal för att signalera något till den som anropat proceduren. Visst kan man göra samma sak med utparametrar, men det finns inget rätt eller fel i det ena eller det andra.

Tänkte skriva någonting men....
Christoffer fick med ungefär det jag tänkte skriva.

//Håkan

Det känns som om mitt resonemang helt missförstås här. Jag försöker inte påstå när olika saker implementerats eller har förnekat att det går att använda RETURN med SP. Det vore korkat av mig att förneka det uppenbara.

Vad jag försöker säga (och här krävs det lite kunskaper i programmeringshistoria) är att procedurer från början är tänkt att inte returnera enskilda tal, utan att funktioner var tänkt för denna uppgiften. Med tiden så har dessa två element, psp och funktioner, flutit ihop allt mer och i praktiken är det sällan skillnad på dessa idag och har som sagt inslag lånade av varandra. Och jag ser inget fel med det.

Vad jag har försökt att säga att även om man kan göra det mesta på flera olika sätt så kan det vara onödigt att krångla till det. Med lite kunspaer i programmeringshistoria i bagaget så kan man ofta se enklare vägar. Därmed inte sagt att andra sätt är fel! I många fall är det dessutom en smaksak.

Så försök inte tolka in andra saker i det jag skriver eller försök lägga ord i min mun.


<b>>Procedurer har funnits i SQL Servers T-SQL betydligt längre än funktioner</b>

Det där är rent ut sagt bullshit. Så länge du pratar om T-SQL så har både funktioner och sp funnits med från början.

I detta fallet blev det lättast att göra på detta sättet. Det finns andra fall jag använder mig av output, men i detta fallet valde jag en return.

<Det där är rent ut sagt bullshit. Så länge du pratar om T-SQL så har både funktioner och sp funnits <med från början.

Och det där är också bullshit, för funktioner som man skapar själv (s.k. User Defined Functions) kom med SQL 2000. Procedurer (inte bara sp=system procedures) har däremot funnits "alltid"

/micke

Vad har programmeringshistorik med denna frågan att göra? Du säger, åtminstone som jag läser det, klart och tydligt i två meddelanden att nyckelordet RETURN (i T-SQL, oavsett hur programmering i största allmänhet fungerar) inte ska användas med lagrade procedurer, vilket jag säger är helt fel. Håkan svarar två gånger helt korrekt på frågan och bägge gångerna kommenterar du att hans svar inte är riktigt bra.

Som Micke skrev så har användardefinierade funktioner inte funnits i SQL Server lika länge som lagrade procedurer. Där var jag tyvärr kanske lite otydlig när jag bara pratade om funktioner, men iom att du skrev som nedan så antog jag att det var just UDFer som diskuterades.

>Det går, som du helt riktigt skriver, att använda RETURN med SP, men det är inte från början tänkt att användas så. RETURN är tänkt att användas med funktioner.

Som sagt, i SQL Server skapades nyckelordet RETURN från början för att returnera ett skalärt värde från en procedur. Notera också att SQL Servers begrepp procedur och funktion (användardefinierad funktion) inte riktigt motsvarar de begrepp du nämner. Det största användningsområdet för användardefinierade funktioner i SQL Server 2000 är som ett alternativ till vyer, där man returnerar en tabellvariabel. Man kan även skapa skalära UDFer, dvs som returnerar ett värde, men dessa går inte att anropa på annat vis än att referera till dem i en SQL-fråga.

hm

om jag inte är helt fel på det så kom udf'er först i och med
sql server 2000 det fanns i alla fall inte i version 6.5
/JW