récupérer un résultat d'une proc stockée dans un prog C#

Bonjour ici.

Bon, j'ai cette procédure (SQL SERVER) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

ALTER PROCEDURE [dbo].[FillPAO]   AS   BEGIN   SELECT dbo.OPCVM.[Code client] AS codcli, dbo.Portfolio.code_opcvm AS codopcvm, dbo.FormateChiffres(dbo.Portfolio.Nombre_de_titres) AS nbtitre, dbo.Assemblée.[Code société] AS codsoc, dbo.Assemblée.[Code assemblée] AS codass, dbo.Assemblée.[Date de tenue d'assemblée] AS dateag INTO #TempPosAg FROM dbo.Assemblée INNER JOIN dbo.Société ON dbo.Assemblée.[Code société] = dbo.Société.[Code société] INNER JOIN dbo.Portfolio ON dbo.Société.[Code société] = dbo.Portfolio.Id_Societe INNER JOIN dbo.OPCVM ON dbo.Portfolio.code_opcvm = dbo.OPCVM.[N°OPCVM]     INSERT INTO [dbo].[Positions_AG_OPCVM]([code_assemblee],[N°OPCVM],[cli], [SharesatRecorddate], [MeetingWithShares]) SELECT codass, codopcvm, codcli, SUM(nbtitre), 1 FROM #TempPosAg WHERE (DATEDIFF(DAY, GETDATE(), dateag) = 3) AND NOT EXISTS (SELECT [code_assemblee],[N°OPCVM],[cli] FROM [Positions_AG_OPCVM]) GROUP BY codass, codopcvm, codcli   SELECT @@ROWCOUNT   END

---

Je veux pouvoir récupérer le résultat du "SELECT @@ROWCOUNT" dans un programme (C#), lors de cette ligne :

Code:

---

int execproc = sqlcmd.ExecuteNonQuery();

---

à l'heure actuelle, je ne récupère que le nombre de lignes traitées au total par la procédure (environ 68800), alors que l'insert n'en insère que 6.
Qui peut me corriger ?
j'ai même essayé d'envoyer plutôt une requète du genre EXEC FillPAO, SELECT @@ROWCOUNT (en retirant la ligne de la procédure, bien sûr)
mais toujours même résultat : environ 68800 lignes au lieu des 6 ajoutées dans l'INSERT.

P.S. : J'ose pas poster également dans C#, ça ferait doublon. A moins qu'un modo y mette un lien, svp.

Essai ExecuteScalar à la place d'ExecuteNonQuery

ou alors tu ajout un paramètre out à ta procédure

Citation:

---

Envoyé par rad_hass

Essai ExecuteScalar à la place d'ExecuteNonQuery

---

genre :

Code:

---

execproc =Convert.ToInt32(sqlcmd.ExecuteScalar());

---

Conversion obligé, apparemment...

Citation:

---

Envoyé par BenoitM

ou alors tu ajout un paramètre out à ta procédure

---

out ? j'ai déjà essayé un RETURN, mais ça marche toujours pas.

Oui ExecuteScalar renvoi Object

Pourquoi utiliser une table temporaire alors que vous pouvez le faire en 1 seule requête (et donc compter le bon nombre de lignes) ?

De plus, il y a quelque question sur votre code à voir ci-dessous :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

INSERT INTO [dbo].[Positions_AG_OPCVM]( [code_assemblee] ,[N°OPCVM] ,[cli] ,[SharesatRecorddate] ,[MeetingWithShares])   SELECT asb.[Code assemblée] , por.code_opcvm , op.[Code client] , SUM(dbo.FormateChiffres(por.Nombre_de_titres)) , 1 FROM dbo.Assemblée asb INNER JOIN dbo.Société sct ON asb.[Code société] = sct.[Code société] INNER JOIN dbo.Portfolio por ON sct.[Code société] = por.Id_Societe INNER JOIN dbo.OPCVM op ON por.code_opcvm = op.[N°OPCVM]   WHERE dateag = dateadd(day, -3, getdate()) -- Attention à un format date heure ou uniquement date ?   -- Pour conversion à la journée si dateag est à la journée et non heure, min, sec. Valable en SQL 2008 -- dateag = dateadd(day, -3, cast(getdate() as DATE) AND NOT EXISTS -- Ne manque-t-il pas quelque chose dans votre exists ? un filtre pour mettre en relation avec le reste de la requête ? (SELECT [code_assemblee],[N°OPCVM],[cli] FROM [Positions_AG_OPCVM])   GROUP BY codass, codopcvm, codcli     SELECT @@ROWCOUNT

---

Pourquoi ?
Parce que cette procédure est lancée chaque jour. Donc, la table destination est susceptible de varier. Et je ne veux compter QUE ce qui vient d'être ajouté, pas ce que contient la table finale.
Ensuite, vos remarques sur la date m'intéresse, j'avais effectivement un défaut d'arrondi (je pense) traduit par une variation de résultat dans la même journée. Mais j'ai écrit

Code:

---

DATEDIFF(DAY, GETDATE(), dateag) = 3

---

(la date d’aujourd’hui doit être inférieure de 3 jours à la dateag)
Enfin, la dernière remarque, je répond non, il ne manque rien. ça marche parfaitement bien :)

pas de bol, DATE n'est pas un type reconnu par le système (SQL SERVER 2005 Express - j'y peux rien ! ;) )