Discussion :

[berceker united]

Bonjour,

Je voudrais savoir s'il y a une vue système permettant de connaitre les paramètres d'une procédure stockée sans avoir besoin de faire une analyse de texte sur l'information retourné par sp_helptext.
Exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE PROCEDURE dbo.Test (@param_1 INTEGER, @param_2 VARCHAR(250))
AS BEGIN
...
END
GO

Que cela puisse me retourner
@param_1 | INTEGER
@param_2 | VARCHAR(250)


Merci

[aieeeuuuuu]

Bonjour,

Vous pourrez trouver toutes ces informations dans la vue INFORMATION_SCHEMA.PARAMETERS

[berceker united]

Bonjour,

Merci pour cette informations, j'aurais du le voir car j'étais resté sur les vues systèmes de la base de données.
Merci

[berceker united]

Mais je reviens sur ma question.
Faut-il utiliser INFORMATION_SCHEMA ou sys.xxx ?

Il me semble qu' INFORMATION_SCHEMA est normalisé.

[aieeeuuuuu]

Il me semble qu' INFORMATION_SCHEMA est normalisé.

C'est le cas.

Seulement, certaines données ne sont présentes que dans les tables système...

[berceker united]

Ok je vais donc surement jongler entre les deux. Mais maintenant je me pose la question si c'est pas plus propre ou utile d'utiliser SMO mais ça l'air un peux plus chaud quand même.

[soazig]

Bonjour,
sp_help te renvoie aussi la réponse , après ça dépends ce que tu veux en faire.

PS: il n'y a pas le text après sp_help ce n'est pas un hasard.
Cordialement
Soazig

[berceker united]

Si ça existe http://msdn.microsoft.com/fr-fr/library/ms176112.aspx

Je veux pas utiliser sp_help car ça me renverrait plusieurs dataset et je préfère utiliser une solution plus simple, plus propre.

En faite, je veux connaitre les caractéristiques des tables (bon ça c'est facile) mais je veux les caractéristique pour les procédures stockée.
Mon but, faire un générateur de données pour peupler une base de données pour teste.

Et souvent les procédures stockées sont oubliées.

[SQLpro]

Les vues d'information de schéma (INFORMATION_SCHEMA) sont garanties et portable car normalisées.
Les vues systèmes peuvent changer au gré des humeurs du staff Microsoft lors des services packs comme lors des versions...

Conclusion : les premières sont destinées à résoudre des problématique stables (application en général), les autres sont à destinations de la cuisine interne (dba par exemple).

A +

[berceker united]

Je pense que je vais privilégier l’interrogation de cette base ou SMO.

[elsuket]

Bonjour,

La requête suivante est valable de SQL Server 2005 à SQL Server 2014 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SELECT		O.type_desc AS module_type
		, O.name AS module_name
		, P.name AS parameter_name
		, TY.name AS parameter_data_type_name
		, CASE WHEN TY.name IN ('nchar', 'nvarchar') THEN P.max_length / 2 ELSE P.max_length END AS max_length
		, P.precision
		, P.scale
FROM		sys.parameters AS P
INNER JOIN	sys.objects AS O
			ON P.object_id = O.object_id
INNER JOIN	sys.types AS TY
			ON TY.system_type_id = P.system_type_id

En bossant un peu, on peut construire la chaîne qui donne le type de données tel qu'on le taperait pour décrire une table en T-SQL.

@++