Warum ein "*" ?
verwendetes Datenbanksystem: Sql Server 2005
So sieht meine Stored Procedure aus:
ALTER PROCEDURE [dbo].[me_CountUsers]
AS
BEGIN
declare @uCount varchar
SET @uCount = (SELECT COUNT(*) FROM aspnet_Membership)
UPDATE me_datastore SET dData = @uCount WHERE dTitle = 'UserCount'
END
Als Ergebnis kommt jedoch ein * heraus anstatt die korrekte Zahl 12. Woran kann das liegen? Versuche einfach nur die Anzahl der Mitglieder zu speichern (stündlich).
Danke!
Bei mir funktioniert eine ähnliche Abfrage(mit anderen Tabellen).
Vielleicht macht es auf folgende Weise ja einen Unterschied:
SELECT @uCount = COUNT(*) FROM aspnet_Membership
Lg XXX
Hallo Paulo,
die Variable "@uCount" ist nicht dafür gekennzeichnet, dass sie zurückgegeben wird, versuche mal folgende Variablendefinition zu verwenden:
DECLARE @uCount INT OUTPUT
Dann sollte es auch richtig funktionieren.
Viele Grüße
Norman-Timo
Edit:
Warum wird die Anzahl als String (varchar) definiert?
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
hallo norman_timo,
Original von norman_timo
die Variable "@uCount" ist nicht dafür gekennzeichnet, dass sie zurückgegeben wird, versuche mal folgende Variablendefinition zu verwenden:DECLARE @uCount INT OUTPUT
die Variable wird ja in der anschliessenden Update-Anweisung innerhalb der Prozedur verwendet, von daher ist das OUTPUT meiner Ansicht nach unnötig. (hab's aber auch nicht gleich gesehen...)
Original von norman_timo
Edit:
Warum wird die Anzahl als String (varchar) definiert?
Das Frage ich mich allerdings auch, vor allem muss bei varchar immer eine Feldgröße angegeben werden, andernfalls wird nur ein Zeichen verwendet, vermutlich daher das "*". Bei varchar(10) wäre das richtige Ergebnis, jedoch als String, herausgekommen.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Hallo yellow,
die Variable wird ja in der anschliessenden Update-Anweisung innerhalb der Prozedur verwendet, von daher ist das OUTPUT meiner Ansicht nach unnötig. (hab's aber auch nicht gleich gesehen...)
Du hast Recht, ich habe mir die Update Anweisung so gar nicht angeschaut, bin davon ausgegangen, dass die Stored Procedure für eine Rückgabe verwendet wird, und nicht, dass eine andere Tabelle upgedatet wird.
-> "UserCount", muss man so etwas in einer separaten Tabelle halten, oder ist es nicht sinnvoller immer ein "Select Count(*)" auf entsprechende Tabelle auszuführen, denn dann ist die Angabe IMMER aktuell und muss nicht noch blöde Trigger einbauen, falls mal User gelöscht werden etc...
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
hallo norman_timo,
Original von norman_timo
-> "UserCount", muss man so etwas in einer separaten Tabelle halten, oder ist es nicht sinnvoller immer ein "Select Count(*)" auf entsprechende Tabelle auszuführen, denn dann ist die Angabe IMMER aktuell und muss nicht noch blöde Trigger einbauen, falls mal User gelöscht werden etc...
ich bin auch ein Fan von Select Count(*) in dem Moment wo es gebraucht wird, habe aber speziell im Webbereich die Erfahrung gemacht, dass alles gepuffert wird. Ich denke hier ist der Geschwindigkeitsvorteil zum Abfragen eines Wertes aus einem Feld ausschlaggebend, und der Verwaltungsaufwand wird in Kauf genommen.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Danke, hab in der Tat die Feldgröße beim varchar vergessen.
Es ist eine Web Applikation und das dynamische Ausführen von SELECT COUNT(*) würde zuviel Performance kosten.
Danke an alle!
hallo Paulo,
hätte ich nur nicht den Hinweis mit der Feldgröße geschrieben. Verwende INT um das Ergebnis von Count(*) zu speichern, genau so wie es auch norman_timo schon sagte.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de