> Tech > Contrôle des données retournées (2)

Contrôle des données retournées (2)

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

A partir du nombre de lignes retourné, vous pouvez peut-être deviner que vous avez commis une erreur, mais si vous n’avez aucune idée de la sortie escomptée, cela peut ne pas vous interpeller immédiatement. La documentation en ligne indique que vous pouvez éviter le problème en capturant les ID dans

Contrôle des données retournées (2)

des variables et en effectuant un contrôle d’erreur sur les valeurs capturées, comme le montre le code du listing 1, avant d’appeler la fonction sys.dm_db_index_physical_stats().

Un problème plus insidieux que j’ai découvert pendant les tests réalisés pour la rédaction de cet article réside dans le fait que SQL Server appelle la fonction object_id() à partir du contexte de votre base de données courante, avant tout appel à la fonction de gestion dynamique (DMF). Je me trouvais dans AdventureWorks, mais je souhaitais des informations sur une table de la base de données Pubs. J’ai donc exécuté le code suivant :

 SELECT * FROM
sys.dm_db_index_physical_stats
(db_id(‘pubs’,
OBJECT_ID(N’dbo.authors’),
null, null, null)
;

Comme ma base de données courante ne comporte aucune table dbo.authors, SQL Server traite la fonction object_id comme NULL et j’obtiens les informations sur tous les objets dans Pubs. Mais si AdventureWorks avait une table dbo_authors, SQL Server utiliserait l’ID de celle-ci pour essayer d’extraire des informations de la base de données Pubs. J’obtiendrais alors soit une erreur indiquant qu’il n’existe pas d’ID d’objet de ce type dans la base de données, soit des données d’une autre table que celle souhaitée. Ce problème pourrait être difficile à résoudre, à supposer que vous deviniez l’existence d’un problème.

La seule solution consiste à définir complètement le nom de la table dans l’appel à la fonction TVF ou, comme dans le code précédent, à employer des variables afin d’obtenir l’ID du nom de table complet. Je trouve étrange de devoir indiquer le nom complet de l’objet avec celui de la base de données si un paramètre spécifie déjà le nom de base de données en question, mais il faudra s’en accommoder. Si vous écrivez des procédures enveloppes pour appeler la fonction sys.dm_db_index_physical_stats(), vous pouvez concaténer le nom de base de données sur le nom d’objet avant de récupérer l’ID d’objet et contourner ainsi le problème. La sortie de cette fonction est mystérieuse et vous souhaiterez probablement écrire une procédure qui accède à cette fonction et retourne les informations sous une forme légèrement plus conviviale.

Le troisième paramètre vous permet de préciser l’ID d’index pour la table spécifiée et, encore une fois, la valeur par défaut NULL signifie que vous souhaitez récupérer tous les index. Le quatrième paramètre indique le numéro de partition et NULL signifie que vous souhaitez, là encore, récupérer les informations pour l’ensemble des partitions. Le cinquième et dernier paramètre est le seul pour lequel la valeur NULL ne retourne pas toutes les informations. Il indique le mode d’échantillonnage adopté par SQL Server lorsqu’il récupère les informations. Les entrées valides sont DEFAULT, NULL, LIMITED, SAMPLED ou DETAILED. La valeur par défaut NULL correspond à LIMITED.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010