Tables en lecture seule

Bonjour,

Je souhaiterais avoir des conseils sur la meilleure manière de procéder pour passer une base SQL en semi lecture seule.
Ma problématique est la suivante.
Une base SQL Server va être migrée dans un nouvel environnement (passage sous un ERP).

Les utilisateurs ne vont plus pouvoir se connecter pour effectuer des insert et des update mais ils doivent pouvoir consulter des données et lancer des impressions.

Ils doivent aussi pouvoir pendant 1 semaine saisir des données dans une table spécifique.

Pour certaines procédures et impressions des tables temporaires sont créées.

Si je passe la base en lecture seule je vais devoir à chaque impression ou chaque saisie concernée passer temporairement la base en écriture puis la repasser en lecture seule.
Idem si je mets les user en db_datareader.

Y aurait-il un moyen de faire autrement ?
Laisser certaines tables en lecture/ecriture et d'autres en lecture seule ou quelque chose de ce genre ?

Quelqu'un aurait-il des conseils à me communiquer ?

Merci par avance.

Bonne journée.

Bonjour,

Vous pouvez passer par les privilèges pour interdire les modifications

Code:

---

1 2	DENY INSERT, UPDATE, DELETE ...

---

Bonsoir

Effectivement cela semble correspondre à ce que je souhaite faire et cela ne me semble pas trop lourd à mettre en oeuvre.

Merci.

Mettre les users en db_datareader + donner les droits d'écriture seulement sur la table question.

Merci

Bonjour,

J'ai essayé les

Code:

---

DENY INSERT, UPDATE on tableName to connectUser

---

Mais cela ne fonctionne pas.

Les update sont effectués.

L'utilisateur connectUser est db_datareader et db_datawriter de la base.

Cela signifie t-il que ces droits prévalent sur les ordres DENY donnés ?

Ou est-ce un problème de syntaxe ?

Merci

Au temps pour moi cela fonctionne.

C'était un problème de privilèges par ailleurs.

Merci.

Attention toutefois avec les privilèges, vu que vous semblez passer par des procédures stockées.

Si le propriétaire de la procédure stockée est le même que le propriétaire des tables, alors l'utilisateur qui a le droits d’exécuter une procédure qui mets à jours des tables ne sera pas bloqué, en raison du chainage de propriété.

Oui mais là justement j'ai le problème inverse.

Si je fais un

Code:

---

Select * from table

---

j'obtiens le résultat.

Mais si je lance une procédure stockée qui fait la même chose j'ai une erreur d'autorisation.

En l'occurrence le propriétaire de la sp est dbo

Une idée ?

Merci

quelle erreur ?

Je pense plutôt a un refus d'execution de la procédure non ?

Oui tout à fait.

Un refus d'exécution de la procédure

Il faut octroyer l'autorisation EXECUTE

Merci.

Oui mais alors cela devient un peu compliqué par rapport à ce que je veux faire.
Car je suis obligé d'accorder des autorisations EXECUTE sur toutes les SP.

Et, dans ce cas, comme je donne aussi des autorisations sur les SP avec des INSERT et des UPDATE, les utilisateurs peuvent à nouveau faire des INSERT et des UPDATE.
Et isoler les SP qui font des INSERT et des UPDATE, sur 1300 et quelques SP pour ne pas leur accorder les autorisations c'est un peu compliqué.

Je ne peux même pas passer la base en lecture seule et la repasser temporairement et selon les besoins en lecture/ecriture car pour faire cela il ne faut qu'un utilisateur connecté.

Je crois que je vais faire cela côté client car je ne vois pas de solution simple.

Bonne journée.

non, vous pouvez appliquer le privilège sur le(s) schéma(s), ou utiliser les vues d'information schéma pour lister les SP et générer les ordres GRANT EXECUTE....

pour le reste, vous pouvez changer le propriétaires des SP pour qu'il soit différent de celui des tables. Ainsi, les privilèges seront vérifiés au moment de l'exécution. Cela peut toutefois avoir des effets de bords si l'existant s'appuie déjà sur le chainage de propriété pour effectuer certaines actions.

Merci,

Je vais fouiller dans cette direction.

Mais effectivement je crains un peu les effets de bord.
Avec les vues, les fonctions...

Merci encore.

Bonne soirée