none
VB.NEt Base ACCESS verrouillée RRS feed

  • Question

  • Bonjour,

     

    J'ai développé un outil en VB.Net qui utilise une base ACCES OleDB.

    Tout se passe bien dans l'environnneent de développement (VS2010).

    J'ai ajouté au projet un projet de déploiement.

    Lorsque j'installe l'outil sous Windows seven.

    L'exe ne semble pas avoir accès à la base ACCESS en ecriture : L'opération doit utiliser une requête qui peut être mis à jour.

    Si je lance l'exe "En tant qu'administrateur" ça fonctionne.

    Comment règler ce problème?

     

     


    FB
    dimanche 18 décembre 2011 23:19

Réponses

  • Le mot "Base Acceess" est finalement un peu exagéré cas il ne s'agit en fin de compte que d'un fichier comme tout les autres.

    Et donc, rien ne vous empêche de l'embarquer comme fichier source dans votre application, puis celle ci pourra le copier, lors de son premier lancement, à en endroit demandant moins de privilèges comme "Applications Data".

    Je suis d'accord avec vous est que le mieux est que ce soit le Setup qui le fait : Pour ce ci il suffit que votre fichier Access ait pour destination un répertoire qui requit moins de privilège comme "Application Data". Cette configuration pourra être  faite vi le menu "Files System" de votre projet Setup.

     

    Cordialement. 

    lundi 19 décembre 2011 21:02
    Auteur de réponse
  • Bonjour Kakworg,

    En effet, les dossiers C:\ et C:\Program Files (x86) nécessitent par défaut des droits d'administrateur.

    "Comment changer la stratégie de sécurité du répertoire de destination du Setup?"

    Ceci n'est pas une bonne manière de faire, mieux vaut encore se placer dans Application Data.

    Votre problème est-il donc résolu ?

    Bonne journée.

     


    N'hésitez pas à poser des questions si un problème subsiste ou quelque chose n'est pas clair. Dans l'autre cas, veuillez indiquer que le problème est résolu. Cordialement - Best Regards. Contact
    vendredi 23 décembre 2011 14:41

Toutes les réponses

  • A priori ceci vient que le fichier ACCESS soit placé dans le répertoire C:\Program Files (x86)

    si je l'ouvre dans ACCESS le problème est équivalent


    FB
    dimanche 18 décembre 2011 23:32
  • Bonjour,

    Une solution consisterait en faire de sorte que ce soit votre exe qui crée la base Access et pas le setup car le setup tourne effectivement avec des privilèges administrateur et tout objet qu'il crée risque de requérir des droits administrateur en  écriture.

    Vous pouvez aussi modifier la protection de sécurité de votre fichier Access, soit directement dans l'explorateur soit via votre setup.

     

    Cordialement.

    lundi 19 décembre 2011 16:35
    Auteur de réponse
  • Euuuuhhh Construire la base ACCESS via mon exe nan, je ne vois pas l'intéret^^

    Par contre adapter la sécurité via le Setup, je suis intéressé. Comment procède t'on?


    FB
    lundi 19 décembre 2011 18:54
  • Le problème vient du répertoire d'installation, l'utilisateur doit avoir un controle TOTAL !!

    Comment changer la stratégie de sécurité du répertoire de destination du Setup?


    FB
    lundi 19 décembre 2011 20:44
  • Le mot "Base Acceess" est finalement un peu exagéré cas il ne s'agit en fin de compte que d'un fichier comme tout les autres.

    Et donc, rien ne vous empêche de l'embarquer comme fichier source dans votre application, puis celle ci pourra le copier, lors de son premier lancement, à en endroit demandant moins de privilèges comme "Applications Data".

    Je suis d'accord avec vous est que le mieux est que ce soit le Setup qui le fait : Pour ce ci il suffit que votre fichier Access ait pour destination un répertoire qui requit moins de privilège comme "Application Data". Cette configuration pourra être  faite vi le menu "Files System" de votre projet Setup.

     

    Cordialement. 

    lundi 19 décembre 2011 21:02
    Auteur de réponse
  • J'avais fait ceci en effet... Je l'ai placé dans le répertoire de l'utilisateur au lancement.

    Quant au fameux débat déjà tellement lancé sur le fait qu'ACCESS soit une base ou non. Ce n'est pas le lieu je pense.

    Encore faut il déterminer la définition précise d'une base.

    Sur le fait que cet outil puisse héberger des données et leur imposer des règles d'intégrité et répondre aux fondement de merise : ACCESS peut le faire

     

    Sur les questions de performance, de sécurité et de fiabilité : non, ce n'est pas une base de données

    Modéliser une base dans ACCESS est déjà un bon début. Après si on a besoin de faire de grosses transactions et des procédures stockées, il n'est plus adapté. 

    Il faut tout de même savoir que BEAUCOUP d'utilisateurs parlent de base de données en  parlant d'EXCEL : PAR CONTRE dans ce cas, je suis contre.

    Cordialement


    FB
    lundi 19 décembre 2011 22:24
  • Bonjour Kakworg,

    En effet, les dossiers C:\ et C:\Program Files (x86) nécessitent par défaut des droits d'administrateur.

    "Comment changer la stratégie de sécurité du répertoire de destination du Setup?"

    Ceci n'est pas une bonne manière de faire, mieux vaut encore se placer dans Application Data.

    Votre problème est-il donc résolu ?

    Bonne journée.

     


    N'hésitez pas à poser des questions si un problème subsiste ou quelque chose n'est pas clair. Dans l'autre cas, veuillez indiquer que le problème est résolu. Cordialement - Best Regards. Contact
    vendredi 23 décembre 2011 14:41
  • Je l'ai contourné, mais j'aimerais bien comprendre pour une prochaine fois.

    Le répertoire Data étant un sous-répertoire de l'application, le problème est équivalent, j'ai testé.


    FB
    vendredi 23 décembre 2011 15:17