[MSSQL] Stored Proc en vars

[G-RaX]

Beste Tweakers,

Ik heb een probleempje met een stored procedure. Ik ben bezig een Webservice te bouwen met vb.net en nu wilde ik een generieke stored procedure maken, om bepaalde statistiek informatie uit de database te halen.

De Query die ik gebruik is als volgt:

SELECT ServerIp, COUNT(ServerIp) as Counted
FROM home.Inetlog
GROUP BY ServerIp
ORDER BY Counted DESC

Nu wil ik een generieke stored procedure hiervoor maken als volgt:

CREATE PROCEDURE spStatsServerTotal

@statsValue as varchar

AS

SELECT @statsValue, COUNT(@statsValue) as Counted
FROM home.Inetlog
GROUP BY @statsValue
ORDER BY Counted DESC
;
GO

Echter, dit vind MSSQL Server niet echt fijn, want als ik deze Stored Proc probeer op te slaan dan krijg ik de volgende error:

Error 164: GROUP BY expressions must refer to column names that appear in the select list

Heeft iemand hier een oplossing voor? Misschien kan ik hem beter hardcoded in mijn webservices maken ipv via een stored proc? Of zijn er betere oplossingen?

Alvast bedankt!

[dominic]

SELECT @statsValue as statsValue, COUNT(@statsValue) as Counted
FROM home.Inetlog
GROUP by statsValue
ORDER BY Counted DESC

[Croccifixio]

G-RaX schreef op 23 augustus 2004 @ 15:28:
[...]

Nu wil ik een generieke stored procedure hiervoor maken als volgt:

CREATE PROCEDURE spStatsServerTotal

@statsValue as varchar

AS

SELECT @statsValue, COUNT(@statsValue) as Counted
FROM home.Inetlog
GROUP BY @statsValue
ORDER BY Counted DESC
;
GO

[...]

Ik vermoed dat MSSQL hier problemen mee heeft. Je kan een group by clause kennelijk alleen toepassen op een letterlijke kolomnaam. Wat ik eens zou proberen is de kolom @statsValue ook een alias geven:

code:

SELECT @statsValue as stats, COUNT(@statsValue) as Counted
FROM home.Inetlog
GROUP BY stats
ORDER BY Counted DESC

[ Voor 35% gewijzigd door Croccifixio op 23-08-2004 15:49 . Reden: quote van TS wat ingekort ]

[whoami]

Ik denk niet dat het nuttig is om voor deze situatie een SP te maken. Integendeel zelfs, het is niet mogelijk om met parameters in je select-list te werken, en je DBMS kan die query niet gaan parsen.

Ik denk dat je in je VB.NET applicatie beter een class / method maakt die die query voor jou gaat gaan opbouwen adhv bepaalde input-variablen, en dat je dan zo die query kunt gebruiken.

[G-RaX]

@ Croccifixio

Die oplossing had ik ook al geprobeerd en dan vind MSSQL het weer een invalid column name...dus dat gaat ook niet werken. Ik denk inderdaad dat er niets anders op zit dan het in een webmethod hard te zetten.

[Infinitive]

Volgens mij kan dit wel. Ik dacht dat ik dat pas in de t-sql documentatie van MSDN gelezen had... maar ik weet niet meer precies hoe...

[Gé Brander]

statement @OPDRACHT opbouwen uit variabelen en deze uitvoeren binnen de sp als 'EXEC (@OPDRACHT)"

[whoami]

c70070540 schreef op 23 augustus 2004 @ 15:43:
statement @OPDRACHT opbouwen uit variabelen en deze uitvoeren binnen de sp als 'EXEC (@OPDRACHT)"

Dat kan je doen, maar dat is gewoon veel te traag. Je stored procedure moet dan met string concatenation die query gaan opbouwen, het dbms kan het beste execution plan niet gaan bepalen, etc....
Dan bouw je beter die query op in je applicatie (webservice), en dan stuur je die query naar de DB.

[Gé Brander]

whoami schreef op 23 augustus 2004 @ 15:48:
[...]


Dat kan je doen, maar dat is gewoon veel te traag. Je stored procedure moet dan met string concatenation die query gaan opbouwen, het dbms kan het beste execution plan niet gaan bepalen, etc....
Dan bouw je beter die query op in je applicatie (webservice), en dan stuur je die query naar de DB.

Ik begrijp alleen niet waarom de dbms niet het beste execution plan zou kunnen bepalen. Uiteindelijk wordt er een opdracht uitgevoerd (select statement) waar dat toch voor zou moeten kunnen?

[EfBe]

c70070540 schreef op 23 augustus 2004 @ 15:57:
[...]

Ik begrijp alleen niet waarom de dbms niet het beste execution plan zou kunnen bepalen. Uiteindelijk wordt er een opdracht uitgevoerd (select statement) waar dat toch voor zou moeten kunnen?

Klopt ook, alleen moet je dan de opgebouwde T-SQL string executeren met EXEC sp_execute.

[zneek]

EfBe schreef op 23 augustus 2004 @ 17:54:
[...]

Klopt ook, alleen moet je dan de opgebouwde T-SQL string executeren met EXEC sp_execute.

Daarnaast is het voordeel van stored procs (compiled sql) dus weg. Zou niets sneller meer moeten zijn dan de query vanuit je app uitvoeren.

[whoami]

De query vanuit de app uitvoeren zal zelfs sneller gaan denk ik.
EfBe heeft een interessant artikel daarover op z'n blog staan.