évolution de DB-MSDE par script SQL

Je viens de faire évoluer une base de données tant au niveau des TABLES que des SP.
J'ai diffusé la mise à jour sous forme d'un Patch appliqué sur mon application à tous les utilisateurs.
Alors que la mise à jour fonctionne sur la plupart des postes. certains sont plantés. Il semble que les scripts SQL ne se soient pas appliqués entierement.
Dans les scripts je fais des :
ALTER et ADD COLUMN, des ADD CONSTRAINT sur des IX et FK et des ALTER PROCEDURE.
J'ai contrôlé pas à pas que tous les scripts étaient appliqués.

est-ce qu'il y a des précautions particlières à prendre, ou une opération de validation générale en fin d'opération ???

je me rends compte que mes SP modifiées par un ALTER PROCEDURE, n'ont pas de gestion de droits de type :
DENY EXECUTE ON [dbo].[My_SP_Name] TO [public] CASCADE
GRANT EXECUTE ON [dbo].[My_SP_Name] TO [My_User_Name]

Par défaut elles auront donc quel droit d'execution ?

Dans la mesure ou je veux en limiter l'utilisation à mon seul User, est-ce que je dois passer un :
DENY EXECUTE ON [dbo].[My_SP_Name] TO [public] CASCADE
GRANT EXECUTE ON [dbo].[My_SP_Name] TO [My_User_Name]
sous forme de script SQL ?
ou sous quelle autre forme, puis obtenir ce résultat ?

pour finir de compléter ma question :
My_User_Name est db_Owner mais n'est pas db_Security admin ni ddl_admin...
dois-je avant de procéder aux évolutions de SP, le passer en db_Security admin et/ou ddl_admin ?
comment ?

merci d'avance à ceux qui pourront m'aider à progresser...

Quelques réponses en vrac :

- db_owner inclut tous les droits, donc tu n'as pas besoin de rajouter d'autres droits. Par contre, pour une gestion plus précuationneuse des droits, il vaudrait mieux enlever ton user de db_owner et lui donner les droits spécifiques.

- Si le user est db_owner, il peut exécuter tes sp sans plus de formalité, sinon tu doit faire un GRANT EXEC. Par défaut, sans aucun droit, les membres de public ne peuvent exécuter les sp. A noter qu'un ALTER conserve les droits précédemment attribués.

- Tu peux ajouter une gestion d'erreur dans tes scripts pour savoir quand ils ont échoué. Regarde aussi l'instruction CREATE SCHEMA dans l'aide en ligne.

Citation:

---

- db_owner inclut tous les droits, donc tu n'as pas besoin de rajouter d'autres droits. Par contre, pour une gestion plus précuationneuse des droits, il vaudrait mieux enlever ton user de db_owner et lui donner les droits spécifiques.

---

Est-ce que ça veut dire que je dois l'enlever de db_Owner et le rajouter dans
db_accessadmin, db_datareader, db_datawriter, db_dlladmin, db_backupoperator ?

Citation:

---

A noter qu'un ALTER conserve les droits précédemment attribués

---

Pas dans mon cas ! ça peut venir de quoi ?

Citation:

---

Envoyé par papouAlain

Est-ce que ça veut dire que je dois l'enlever de db_Owner et le rajouter dans
db_accessadmin, db_datareader, db_datawriter, db_dlladmin, db_backupoperator ?

---

A mon avis, les roles db_datareader et db_datawriter suffisent d'une manière générale, en espérant que tu ne gères pas l'administration et les backup dans ton application.

En effet je ne gère pas l'adminsitration de la DB, mais l'application gère les backup...

Alors tu ajoutes le rôle db_backupoperator aussi.

Par contre j'ai pas encore trouvé dans le T-SQL comment rajouter des rôles...
un p'tit coup de pouce synthaxe, SVP...

sp_addrole
sp_addrolemember