Version imprimable
Bonjour,
Je souhaitera avoir un outil qui me donne toutes les références utilisées par une SQL Procédure en Transact-SQL.
Par références j'entends le nom des tables et colonnes qui sont utilisées dans le SQL proc.
P.S: un truc mieux que Visual Expert ;-)
Merci
Personne pour me donner un coup de main sur ce problème?
Idéalement je recherche une API (peu importe le language) qui prenne en input une procedure SQL sous forme de fichier (Sybase Transact-SQL) et qui ressorte en output toutes les tables/colonnes qui sont référencées dans cette proc.
Je veux pouvoir lancer çà en batch.
8O
Bonjour,
Sous Management Studio vous pouvez faire un clic-droit sur un module SQL pour obtenir la liste des tables et des autres modules dont il est dépendant, mais vous n'avez pas les colonnes.
Vous pouvez requêter sys.sql_denpendencies pour obtenir ces dépendances, mais là encore vous n'aurez pas les colonnes.
Vous pouvez croiser cela avec sys.sql_modules, sys.parameters et sys.columns pour obtenir respectivement le code complet des modules, leurs paramètres, et la liste des colonnes des tables ...
Le "mieux" serait de dépouiller le code de vos modules avec des expressions régulières, mais là, bon courage ;)
@++ ;)
ATTENTION : le contenu de ces tables n'est pas toujours cohérent. En effet vous avez le droit de créer une procédure qui appelle une autre procédure qui n'a pas encore été créé ! D'où un manque dans les données renvoyées par une telle requête...
A +
Personne pour m'aider sur ce sujet ?
C'est pas trop urgent, c'est juste que je vais perdre mon job si je trouve pas une solution (blague :mouarf:)
Salut,
8O à ma connaissance ce genre d'outils n'existe pas, en tout cas pas dans le sens de l'analyse que tu souhaites effectuer. Les seuls outils qui fassent à peu près cela sont les profiler qui tracent les graphes de dépendance des objets en cours d'exécution.
Cette procédure fait-elle 2000 lignes qui appellent des dizaines d'autres procédures ? Dans ce cas, ... :aie:
Sinon: c'est quoi le but de cette analyse ? Si c'est de ne pas comprendre ce que fait la procédure et de simplement lister les dépendances alors ... fait un programme qui recherche toutes les clauses From (avant on trouve les colonnes, après on trouve le nom des tables et des vues utilisées) et tous les mots commencant par 'sp_' (on trouve les procédures stockées). Et pour chaque table il te faut lister les dépendances de cette table (Foreign Key) et pour chaque procédure trouvée à nouveau la même analyse. On peut faire cela à la mano avec de l'entrainement !
Si tu perds ton emploi à cause d'une procédure stockée, il ne te restera plus qu'à devenir développeur Smalltalk, ce qui est une cause noble en soi :)
Le but est d'effectuer une analyse d'impact basé sur des changements de database structure et sur des changements de valeurs possible pour les champ.
J'ai déjà généré tous les points d'impacts: comparaison entre DB version 1 et DB
version 2. Plus une petite popote maison qui permet de générer des points d'impacts à partir de changement de valeur de champ.
J'ai donc maintenant une liste de "table.colonne" (ce que j'appelle points d'impacts).
Il me reste maintenant à trouver toutes les références table.colonne appelées dans les procs.
Ensuite une petite jointure et mon analyse d'impact est terminée.
Le problème de l'analyse syntaxique, c'est que c'est super long à faire et que les possibilité d'erreur ou d'omission sont grande: il me faut pouvoir gérer les where clause, les différents type de jointure, les truncate, delete, update...
Le software VisualExpert me donne exactement l'output dont j'ai besoin mais je veux pouvoir faire des exports massifs et pouvoir gérer tout çà en batch. Ce qui n'est pas possible actuellement avec ce soft.
Enfin voilà vous savez tout.
Il y aurait peut être une autre piste si je pouvais récupérer toutes les infos lors de la compilation (une sorte de compilation en mode verbeux) mais je sais pas si c'est possible...
Ceci est impossible à faire si vous n'avez pas en place une norme de nommage FORTE comme je le préconise depuis des années !
http://www.sqlspot.com/Norme-de-developpement.html
A +
oki avec toi le modo, mais ne serait il pas possible de récupérer ces infos au moment de la compil des procs.
Parce que durant la compilation, le compilateur il va les vérifier toutes les références utilisées dans la proc. Or pour les vérifier, il doit les avoir trouvé...
Pas exactement :
C'est de là que vient le problème ;)Citation:
Envoyé par SQLPro
Si vous compilez un module qui en appelle une autre qui n'a pas encore été créé, Management vous le signale, mais compile le module ;)
@++ ;)