Discussion :

[cavo789]

Bonjour

Ces quatres derniers mois, j'ai développé une grosse DB SQL 2005 et j'ai adapté un grand nombre d'applications pour utiliser la DB. Aujourd'hui, je suis fin prêt à faire transporter mon travail en production et là, patatras, les droits d'accès sur le serveur de production sont plus restrictifs.

J'ai un vrai doute par rapport à ce que mon département informatique me dit aussi, si quelqu'un pouvait confirmer / infirmer, ce serait sympa. Voila :

J'utilise un user spécifique pour me connecter à la DB et pour accéder aux views, user defined functions (udf) et pour exécuter les stored procedure. En DEV comme en PRO, aucun soucis pour accéder aux views et aux udf.

Par contre, pour les stored procedures, c'est une autre histoire :

• si la stored procedure ne fait que retourner une donnée et/ou un recordset, pas de soucis.
• si la stored procedure met à jour une table (update, delete, insert); cela ne fonctionne pas. "En effet" mon user n'a pas de droits en update sur les tables.

Mon département IT me demande donc de lister la liste des tables mises-à-jour via des sp afin de donner un droit update. Est-ce bien la meilleure manière de faire ? Je suis sûr d'avoir lu qu'un user pouvait ne pas avoir accès en direct à une table mais que si la table est utilisée par une sp auquel il a accès alors "l'accès" lui est donné "au travers" de la sp. N'en est-il pas de même pour les updates ?

Merci pour vos suggestions

[cavo789]

Bonjour à tous. Je me permets de faire remonter ce message afin de voir si quelqu'un à une idée (sinon, tant pis).

Merci

[WOLO Laurent]

Oui mais à une condition :
Les objects manipulés dans la procédure stockée doivent avoir le même schema !
Est ce le cas pour toi ?

[cavo789]

Oui c'est le cas. Je déduis donc que mon raisonnement est logique et que je dois demander à mon département informatique de donner les accès nécessaires sur le schéma.

Merci Laurent.