Discussion :

[PickEpique]

Bonjour

Dans un ERP maison adossé à SQL Server standard 2017 je souhaite permettre d'enregistrer des fichiers windows dans un filetable
l'option NON_TRANSACTED_ACCESS du FILESTREAM est à FULL
le filetable a une arborescence complète autocrée de dossiers de fond en fonction des modules et des types de documents de base de donnée
Je souhaite ouvrir l'explorateur windows sur le dossier adéquat en fonction du contexte cela c'est facile à faire
(l'explorateur windows pour pouvoir bénéficier d'un shell complet: aperçu .. etc)
Bien sur, avec l'explorateur l'utilisateur peut naviguer totalement hors du contexte
(y compris d'ailleurs sur des bases de données qui ont leur FileStream sur le même disque et pour lesquelles il a aussi des droits)
ce n'est pas en soit gènant mais il faudrait au moins qu'il ne puisse pas toucher à ma structure de fond (renommer, déplacer, supprimer)
J'avais pensé à RLS (Row Level Security) avec un Filter Predicate ou un block Predicate
Mais RLS semble impossible sur un filetable du moins en version 2017
Comment faire (les ACL sont non implémentés sur les filetables)

Pickepique

[SQLpro]

Vue + déclencheur INSTEAD OF ?

A +

[PickEpique]

Je pense que SQL server lit directement dans le filetable pour afficher les fichiers dans l'explorateur windows
Je ne vois pas comment dire à SQL server d'utiliser une vue à la place et un trigger sur cette vue en cas de mise à jour

Pickepique

[PickEpique]

Bon je poursuis
à Fred Brouard, je n'ai pas vraiment compris votre allusion à une vue
si vous pensez à une vue updatable sur le filetable , cad avec des trigger Instead of -> gestion de la création du fichier dans une PS; c'est ce qu'il y a aujourd'hui
mais ce n'est pas très souple et je voudrais tout simplement lancer un explorateur sur un dossier ou tout se fait, (création suppression, edition, lancement extentions du shell, sur des fichiers )

Pour poursuivre ma tentative, un truc que je n'avais pas essayé.
on peut poser un trigger AFTER, INSERT, DELETE, UPDATE sur un filetable
si je pose un AFTER DELETE sur lequel je teste la condition "est_un_dossier_de_fond" = 1 (grâce à une table associée par exemple qui contient cette colonne)

Pour tester je créé un trigger after delete avec juste:
un "rollback tran"
la suppression de l'élément est effectivement bloquée dans l'explorateur Windows si c'est un dossier
la suppression de l'élément parait effective si c'est un fichier mais un refresh le fait réapparaitre

un "raiserror" dans le trigger
même chose

un peu déroutant pour l'utilisateur, mais comme pour mon cas je veux empêcher la suppression des dossiers de fond cela pourrai me convenir
Est ce une façon fiable de procéder

[SQLpro]

rollback + raiserror pour donner l'information

A +

[PickEpique]

merci