Meilleur auteur de réponses
catch sqlException : Autorisation refusée

Question
-
Bonjour,
Est ce que je peux catcher une SqlException de type "... L'autorisation UPDATE/INSERT a été refusée sur XXX ..."
dans mon formulaire, si l'usager n'a pas les droits suffisants sur l'un des champs de la table ou sur la table entière, je dois lui envoyer un message personnalisé
est ce que dans le catch(sqlException) je peux disinguer ces exceptions par un code par exemple ?
Merci d'avance
Réponses
-
Bonjour,
est-ce que tu as essayé les n° d'erreur 229 ou 230 ? cf. http://msdn.microsoft.com/fr-fr/library/cc645611%28v=sql.100%29.aspx
catch (SqlException e) { switch (e.Number) { case 230: // Faire quelque chose. break; default: throw; } }
Cordialement.- Modifié Hervé DORIER jeudi 22 novembre 2012 19:56
- Proposé comme réponse Hervé DORIER jeudi 22 novembre 2012 19:56
- Non proposé comme réponse Hervé DORIER vendredi 23 novembre 2012 17:03
- Proposé comme réponse Hervé DORIER vendredi 23 novembre 2012 17:05
- Marqué comme réponse Aurel Bera mercredi 28 novembre 2012 13:18
Toutes les réponses
-
Bonjour,
est-ce que tu as essayé les n° d'erreur 229 ou 230 ? cf. http://msdn.microsoft.com/fr-fr/library/cc645611%28v=sql.100%29.aspx
catch (SqlException e) { switch (e.Number) { case 230: // Faire quelque chose. break; default: throw; } }
Cordialement.- Modifié Hervé DORIER jeudi 22 novembre 2012 19:56
- Proposé comme réponse Hervé DORIER jeudi 22 novembre 2012 19:56
- Non proposé comme réponse Hervé DORIER vendredi 23 novembre 2012 17:03
- Proposé comme réponse Hervé DORIER vendredi 23 novembre 2012 17:05
- Marqué comme réponse Aurel Bera mercredi 28 novembre 2012 13:18
-
-
Bonjour,
Il me semblerait plus élégant de vérifier d'abord que l'utilisateur a bien le droit de faire l'action plutôt que de lancer l'action et de traiter l'erreur. Cela permet aussi d'avoir une interface adaptée (inutile de laisser l'utilisateur saisir qq chose pour lui dire ensuite à la validation qu'il n'avait pas le droit de le faire).
Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
-
-
Ces informations sont en fait déjà dans SQL Server. Je pensais à qq chose comme :
SELECT Table_Name, HAS_PERMS_BY_NAME(Table_Name,'OBJECT','DELETE') AS CanDelete, HAS_PERMS_BY_NAME(Table_Name, 'OBJECT', 'INSERT') AS CanInsert FROM Information_Schema.Tables WHERE Table_Type='BASE TABLE'
Il serait donc sans doute assez facile d'exploiter ces infos pour créer qq fonctions de vérifications des droits et ne proposer à l'utilisateur que les actions qu'il pourra effectivement réaliser (comme le font la quasi totalité des applications qui gèrent des données).
Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
-
Sympa la requête ! Je vais la mettre dans mon Wiki perso... ça pourra servir un jour !
Partons de l'hypothèse qu'un formulaire avec 10 champs répartis sur 2 tables. Au lancement il faudrait :
- un traitement qui liste les tables et champs du formulaire
- faire les 2 requêtes qui vont bien en utilisant des "or" (1 req pour les tables, 1 req pour les champs)
- tester tous ces booleens
Ok Patrice, tu as raison, c'est effectivement jouable... à voir en terme de perf.
-
Bonjour,
Est-ce que vous avez testé les solutions proposées ? Merci de partager avec nous les résultats, afin que d'autres personnes avec le même problème puissent profiter de cette solution.
Cordialement,
Aurel
-
Bonjour,
Pouvons-nous considérer que vous avez résolu votre problème avec les scénarios proposés ? Dans l'affirmative, pourriez-vous partager avec nous la solution, afin que d'autres personnes avec le même problème puissent profiter de cette solution ?
Désormais, nous marquons les solutions proposées. N'hésitez pas à revenir et supprimer la réponse marquée si la solution n’est pas correcte. Merci !
Cordialement,
Aurel