bonjour

je cherche à obtenir le schéma d'une procédure stockée, comment puis-je
faire ?
je sais recuperer la liste des parametres qu'elle attend, mais comment
obtenir la liste des colones qu'elle renvoie par le biais d'un select, si
toute-fois c'est possible, et bien sur dans les cas ou ce typage est
"statique".

pour l'instant, j'ai baissé les bras et je m'oriente sur une solution à base
d'analyse syntaxique...

d'avance merci pour vos informations

Dans : news:Ubo1j.290$J12.104@nntpserver.swip.net,
Ambassadeur kosh disait :
> bonjour

Bonjour,

> je cherche à obtenir le schéma d'une procédure stockée, comment
> puis-je faire ?
> je sais recuperer la liste des parametres qu'elle attend, mais comment
> obtenir la liste des colones qu'elle renvoie par le biais d'un
> select, si toute-fois c'est possible, et bien sur dans les cas ou ce
> typage est "statique".

J'avais posé une question fort semblable il y a peu.
Schéma d'une commande Select, le 20/09/2007 à 21:10
N'ayant pas obtenu de réponse (car il n'y en a peut-être pas !) Je me
suis rabattu sur une dll .NET
Oserais-je te préciser que j'ai utilisé GetSchemaTable sur un
SqlDataReader ? :-)
Bien sûr cela n'est possible qu'à partir de la version 2005.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

Fred a écrit :
> Dans : news:Ubo1j.290$J12.104@nntpserver.swip.net,
> Ambassadeur kosh disait :
>> bonjour
>
> Bonjour,
>
>> je cherche à obtenir le schéma d'une procédure stockée, comment
>> puis-je faire ?
>> je sais recuperer la liste des parametres qu'elle attend, mais comment
>> obtenir la liste des colones qu'elle renvoie par le biais d'un
>> select, si toute-fois c'est possible, et bien sur dans les cas ou ce
>> typage est "statique".
>
> J'avais posé une question fort semblable il y a peu.
> Schéma d'une commande Select, le 20/09/2007 à 21:10
> N'ayant pas obtenu de réponse (car il n'y en a peut-être pas !) Je me
> suis rabattu sur une dll .NET
> Oserais-je te préciser que j'ai utilisé GetSchemaTable sur un
> SqlDataReader ? :-)
> Bien sûr cela n'est possible qu'à partir de la version 2005.
>
Il n'y a en effet pas de possibilité de récupérer la liste des colonnes
d'un select d'une PS tout simplement parce qu'une PS peut renvoyer
plusieurs SELECT. C'est donc à vous d'analyser votre code.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

Dans : news:OyEqtZmLIHA.3356@TK2MSFTNGP02.phx.gbl,
Fred BROUARD disait :

> Il n'y a en effet pas de possibilité de récupérer la liste des
> colonnes d'un select d'une PS tout simplement parce qu'une PS peut
> renvoyer plusieurs SELECT. C'est donc à vous d'analyser votre code.

Bonjour,
Dois-je comprendre qu'il y aurait une solution dans le cas d'un simple
SELECT (ma question du 20/09) ?
Par simple curiosité car la méthode que j'ai finalement utilisée
convient pour notre application.

--
Fred (troisième du fil)
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

Bonjour

Non, pas de solution dans ce cas non plus.

Une alternative serait de remplacer la procédure stockée par une fonction
utilisateur de type table multi-instruction.

Christian Robert
MVP SQL Server
http://blogs.codes-sources.com/christian


Hello Fred,

> Dans : news:OyEqtZmLIHA.3356@TK2MSFTNGP02.phx.gbl, Fred BROUARD disait
> :
>
>> Il n'y a en effet pas de possibilité de récupérer la liste des
>> colonnes d'un select d'une PS tout simplement parce qu'une PS peut
>> renvoyer plusieurs SELECT. C'est donc à vous d'analyser votre code.
>>
> Bonjour,
> Dois-je comprendre qu'il y aurait une solution dans le cas d'un simple
> SELECT (ma question du 20/09) ?
> Par simple curiosité car la méthode que j'ai finalement utilisée
> convient pour notre application.

Ok pour le GetSchema du DataReader, mais...

- je ne peux pas "deviner" un ensemble de valeurs pour les parametres qui va
me donner une sortie : si ma proc test les valeurs, et part en erreur, c'est
cuit.

- le but étant de constituer un catalogue, je vais "essayer" toutes les
procs. je risque donc d'en executer une suceptibles de faire le b... dans la
base de dev.

cependant, votre methode est dans pas mal de cas un bon moyen d'arriver au
resultat.

alors, j'hesite...


> Bonjour,
> Dois-je comprendre qu'il y aurait une solution dans le cas d'un simple
> SELECT (ma question du 20/09) ?
> Par simple curiosité car la méthode que j'ai finalement utilisée convient
> pour notre application.

déja, merci à vous tous pour vos contributions.

> Une alternative serait de remplacer la procédure stockée par une fonction
> utilisateur de type table multi-instruction.


ça a l'air effectivement de mieux convenir qu'une store proc pour le besoin,
déja au niveau definition.

j'imagine que je vais trouver les meta-données dans les habituels sysobjects
et syscolumns, non ?

à vos conaissances à chacun, y'a t'il des choses à savoir concernant les
plans d'optimisation, l'execution, bref la perf par rapport à un select
identique fait dans une sp ? j'imagine que c'est pareil, mais sait on
jamais...

et je renouvelle mes remerciements à chacun, j'apprend beaucoup avec vous
tous, c'est vraiment sympa


Frédéric

Dans : news:wbS1j.19$yE.53@nntpserver.swip.net,
Ambassadeur kosh disait :
> Ok pour le GetSchema du DataReader, mais...
>
> - je ne peux pas "deviner" un ensemble de valeurs pour les parametres
> qui va me donner une sortie : si ma proc test les valeurs, et part en
> erreur, c'est cuit.

Oui.

> - le but étant de constituer un catalogue, je vais "essayer" toutes
> les procs. je risque donc d'en executer une suceptibles de faire le
> b... dans la base de dev.

Il y a les transactions éventuellement.

> cependant, votre methode est dans pas mal de cas un bon moyen
> d'arriver au resultat.
>
> alors, j'hesite...

À la réflexion, je crois que ma méthode n'est pas applicable pour une
procédure stockée :-(
Je ne suis pas sûr qu'un assembly .NET puisse effectuer des updates en
base. Or une procédure stockée est sensée pouvoir le faire.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

string sql = "UPDATE ..."
SqlCommand command = new SqlCommand(sql,connection) ;
command.ExecuteNonQuery() ;

si si, je vous affirme que ça marche tres bien.
la plupart du temps meme, on a aucun interet à stocker ça en sp, c'est bien
aussi efficace comme ça.
regardez du côté du SqlCommandBuilder qui fabrique les 4 procs de base pour
les DataAdapter.

Cordialement,

Frédéric

Christian Robert a écrit :
> Bonjour
>
> Non, pas de solution dans ce cas non plus.

Pas tout à fait. Parce qu'un SELECT quel qu'il soit peut être instancié
sous forme de vue. DOnc on peut récupérer la structure des colonnes en
interrogeant la vue d'information de schéma :
INFORMATION_SCHEMA.COLUMNS.

exemple :

USE tempdb
GO

CREATE VIEW V_TEST
AS
SELECT *
FROM Northwind.dbo.Employees
GO

SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'V_TEST'
GO


>
> Une alternative serait de remplacer la procédure stockée par une
> fonction utilisateur de type table multi-instruction.
>
> Christian Robert
> MVP SQL Server
> http://blogs.codes-sources.com/christian
>
>
> Hello Fred,
>
>> Dans : news:OyEqtZmLIHA.3356@TK2MSFTNGP02.phx.gbl, Fred BROUARD disait
>> :
>>
>>> Il n'y a en effet pas de possibilité de récupérer la liste des
>>> colonnes d'un select d'une PS tout simplement parce qu'une PS peut
>>> renvoyer plusieurs SELECT. C'est donc à vous d'analyser votre code.
>>>
>> Bonjour,
>> Dois-je comprendre qu'il y aurait une solution dans le cas d'un simple
>> SELECT (ma question du 20/09) ?
>> Par simple curiosité car la méthode que j'ai finalement utilisée
>> convient pour notre application.
>
>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

Dans : news:7uY1j.125$yE.18@nntpserver.swip.net,
Ambassadeur kosh disait :
> string sql = "UPDATE ..."
> SqlCommand command = new SqlCommand(sql,connection) ;
> command.ExecuteNonQuery() ;
>
> si si, je vous affirme que ça marche tres bien.
> la plupart du temps meme, on a aucun interet à stocker ça en sp,
> c'est bien aussi efficace comme ça.
> regardez du côté du SqlCommandBuilder qui fabrique les 4 procs de
> base pour les DataAdapter.

Ah ! Je parlais d'un assembly qu'on intègre dans SQL Server.
Si cela ne pose pas de problème de coder cela dans une application,
alors bien sûr il n'y a pas de contre-indications.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

Dans : news:%23WosGqsLIHA.1208@TK2MSFTNGP03.phx.gbl,
Fred BROUARD disait :
> Christian Robert a écrit :
>> Bonjour
>>
>> Non, pas de solution dans ce cas non plus.
>
> Pas tout à fait. Parce qu'un SELECT quel qu'il soit peut être
> instancié sous forme de vue.


Je n'avais pas pensé à cette solution toute simple. Merci.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)