Hej !!

Jag har 2 inparametrar till min sp, nu skulle jag vilja
använda en av dessa i select satsen, kan man göra så
på något enkelt sätt ?

så skulle jag vilja göra ;-)

alter proc test
@id int,
@type int
as
select Table1.[@type]
FROM Table1
WHERE Table1.id=@id

/Johan

alter proc test
@id int,
@type int
as
select @type
FROM Table1
WHERE Table1.id=@id


eller menade du inte så?

@type är ett column namn i tabellen Table1 i mitt fall heter
columnerna 1,2,3,4 och 5.
Inparameternm @type är alltså den columnen jag vill läsa ifrån.

/Johan

Då får du skapa en SQL sats som en sträng, och exekvera den med sp_executesql (eller EXECUTE). Kolla mitt tips på min site för mer info om detta.

http://hedgate.edithispage.com/2001/04/02

Är det alltså det enda alternativet ?
Skulle helst vilja slippa stränghantering i sp'en.

Är det nån som vet prestanda skillnaden mellan stränghantering
eller case, if satser ??

/Johan

create procedure x @id int,@type int
as
begin
select case @type when 1 then c1
when 2 then c2
when 3 then c3
when 4 then c4
when 5 then c5 end as c
from t where id = @id
end

är effektivare än använda exec med en sträng.

I och för sig så tycker jag att om man har behov att ställa sådana frågor så har man en suspekt datamodell.

Tänk på att den får göra jämförelsen för varje post. Mycket bättre att ställa upp en ifsats.

create procedure x @id int,@type int
as
begin
IF @type = 1
SELECT c1
FROM Tabell
WHERE id = @id
ELSEIF @type = 2
SELECT c2
FROM Tabell
WHERE id = @id
ELSEIF @type = 3
SELECT c3
FROM Tabell
WHERE id = @id
ELSEIF @type = 4
SELECT c4
FROM Tabell
WHERE id = @id
ELSEIF @type = 5
SELECT c5
FROM Tabell
WHERE id = @id
END

Osäker på syntaget. Men tror det bär funka.

Jag håller med Andreas om att det är bättre att använda IF än CASE i detta fallet, och håller även med Lars om att datamodellen verkar suspekt.... Däremot håller jag inte med om att man inte ska använda en sträng med SQL som exekveras dynamiskt, av följande skäl:

* Det är inte säkert att man vet hur många kolumner som @type kan 'vara'. Även om man vet det så måste man skriva om proceduren när ytterligare en möjlig kolumn läggs till.

* Om man exekverar SQL-strängen enligt det tips jag nämnde så får man inga större prestandaproblem. Att skapa SQL-strängen tar ingen kraft, och om man sedan använder sig av sp_executesql så får man en separat exekveringsplan, kompilerad och klar, för varje sträng, och i praktiken kommer det att bli i princip som att ha flera olika procedurer att anropa från klienten.