none
MembershipProvider : trou de mémoire on dirait RRS feed

  • Question

  • Bonjour tout le monde,

    Histoire d'arrêter un peu d'appuyer sur F5 à chaque tentative de connexion en début de session de travail, j'ai mis ceci dans mon Web.config dans le but d'ajouter ultérieurement "Connection Timeout=180000" (pour trois minutes) à la chaîne de connexion (encore s'agit-il d'en avoir une pour commencer).

      <add name="ServicesConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\ASPNETDB.mdf;Integrated Security=True;User Instance=True"
       providerName="System.Data.SqlClient" />
     </connectionStrings>
     <system.web>
       <membership>
         <providers>
           <add name="AspNetMembershipProvider" connectionStringName="ServicesConnectionString" type="System.Web.Security.SqlMembershipProvider" />
         </providers>
       </membership>

    En l'état ça marche très bien, mais nous sommes d'accord que c'est comme si je n'avais rien fait. C'est au moment où j'ajoute à la balise ouvrante de membership :  defaultProvider="AspNetMembershipProvider",

    qu'on me répond "Your login attempt was not successful. Please try again."

    Je me dis donc que j'ai dû me tromper quelque part.

    Quand on va m'avoir dit où ça sera probablement évident, mais là ...

    Ah l'outil de configuration ASP.Net me rappelle que le fournisseur par défaut s'appelle AspNetSqlProvider. Mais ça ne suffit pas encore.

    Est-ce que je dois dériver le fournisseur juste pour préciser la chaîne de connexion ?


    • Modifié Gloops mercredi 18 juin 2014 15:01
    mercredi 18 juin 2014 13:58

Réponses

  • Une fois que j'ai copié la balise (add name= ...) du MembershipProvider, depuis machine.config vers le Web.config de l'application, j'obtiens bien une balise valide, sous réserve de la précéder de clear ou remove pour éliminer celle de machine.config.

    Je peux aussi personnaliser la chaîne de connexion en la copiant vers le Web.config de l'application, à la même réserve, éliminer celle de machine.config par clear ou remove. D'ailleurs, ceci fait, la balise du MembershipProvider du machine.config fait l'affaire, la chaîne de connexion peut être cherchée dans le Web.config si elle porte le même nom.

    Donc, l'erreur semble-t-il est que je n'avais pas mis un type suffisamment précis, il manquait tout ce qui vient après la virgule.

    Une fois la chaîne de connexion récupérée dans le Web.config, j'ai pu jouer avec. J'ai remplacé SQLEXPRESS par SQLEssePRESS, et j'ai eu droit à une grosse injure pleine page, donc c'est bien cette chaîne de connexion qui était en œuvre. Au niveau du nom de base c'est moins catégorique. Dans la chaîne de connexion j'ai mis |DataDirectory|\Faux.mdb, et la connexion s'est faite. Dans le répertoire j'ai renommé ASPNETDB.MDF en AxPNETDB.MDF, là il ne faut pas exagérer, la connexion ne s'est pas faite. Dans le répertoire je me retrouvais avec AxPNETDB.MDF, ASPNETDB.MDF, et FAUX.MDF.

    Il semblerait donc que la plateforme cherche la base avec le nom indiqué dans la chaîne de connexion, si elle ne la trouve pas elle cherche ASPNETDB.MDF, et si elle ne la trouve pas non plus elle crée une base, ou les deux. Je n'ai pas poussé les investigations plus loin.

    La phase qui entre dans le vif du sujet, maintenant. A la fin de la chaîne de connexion j'ai ajouté ";Time out=120", et j'ai eu une page d'erreur avec  Time Out non reconnu. J'ai enlevé l'espace, plus d'erreur, connexion correcte.

    Je crois qu'on peut donc dire que la question du début du fil a sa réponse.

    Toutefois maintenant que j'ai mis un doigt dans l'histoire de la user instance, j'aimerais bien comprendre un peu plus, comme je disais quelques renseignements me paraissent contradictoires.


    • Modifié Gloops jeudi 3 juillet 2014 18:24
    • Marqué comme réponse Aurel Bera vendredi 4 juillet 2014 07:16
    jeudi 3 juillet 2014 18:18

Toutes les réponses

  • Bonjour,

    Je ne suis pas sûr d'avoir tout compris, notamment pour le coup de la chaîne de connexion^^ (car 3 minutes pour du web c'est énorme), mais il suffirait de faire qqc du genre

    <membership defaultProvider="AspNetMembershiprovider">

    Bien cordialement,

    Fabrice JEAN-FRANCOIS

    jeudi 19 juin 2014 10:07
  • Bonjour,

    Je me permets d'attirer votre attention sur ces trois lignes de mon message d'origine :

    C'est au moment où j'ajoute à la balise ouvrante de membership :

    defaultProvider="AspNetMembershipProvider", qu'on me répond "Your login attempt was not successful. Please try again."

    J'ai aussi essayé la même chose en remplaçant AspNetMembershipProvider, aux deux endroits, par AspNetSqlProvider.

    C'est vrai qu'en matière de délai j'ai vraiment prévu large. Le message à l'attention du système est "le serveur est bien lent mais il finit toujours par répondre, donc il faut l'attendre." Bien entendu, la contrepartie c'est que si un jour il est carrément en panne je risque de trouver le temps long, mais au moins ce n'est plus la peine de jouer avec F5.

    D'ailleurs, une fois que j'aurai trouvé la bonne syntaxe je pourrai tâtonner un peu. A défaut de cela, je peux mettre n'importe quoi pour cette valeur le résultat sera le même.

    jeudi 19 juin 2014 13:29
  • Bonjour Gloops

    Ce problème est toujours d'actualité?

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 2 juillet 2014 06:52
  • Bonjour,

    Oui, je ne sais toujours pas changer le "time out" (tiens comment ça se dit en Français déjà ?) du fournisseur par défaut AspNet.

    ça me faisait l'effet d'une question bateau, et finalement ça n'a pas l'air si évident que ça.

    Alors je continue d'appuyer, assez souvent, sur la touche F5.

    Une autre solution sera de changer de machine, mais c'est plus cher.

    mercredi 2 juillet 2014 08:28
  • Essayez de ajouter : 

     <add name="AspNetMembershipProvider" commandTimeout ="30" connectionStringName="ServicesConnectionString"  type="System.Web.Security.SqlMembershipProvider" />

    En effet le temps spécifié dans le String de connexion indique le temps à attendre seulement pour l’ouverture de la connexion, pas pour l'exécution d'une commande.
    On a aussi la propriété SqlCommand.CommandTimeout pour spécifier le tems a attendre pour l'exécution d'une commande SQL et ce temps vous le modifiez avec la propriété ajoute au  AspNetMembershipProvider  .

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 2 juillet 2014 08:48
  • En fait, c'est surtout pour établir la première connexion que c'est long, à telle enseigne que parfois j'ouvre la base dans l'explorateur de serveurs avant de lancer l'exécution de l'application, histoire de réveiller SQL Express -mais ces temps-ci j'ai un peu tendance à oublier de faire ça.

    Alors je peux ajouter des propriétés dans add name, mais avec les propriétés que j'ai déjà mises, au moment où je déclare cet élément name comme fournisseur par défaut, la connexion échoue avec un message signifiant que ce fournisseur n'existe pas, ou une variante (voir ci-dessus).

    Voilà qui laisse à penser, peut-être, que le problème n'est pas tellement dans les propriétés qu'on peut ajouter à cette balise, mais dans le fait d'être capable de la faire reconnaître comme fournisseur par défaut. Le principe est simple, il faut mettre son nom dans defaultProvider au niveau de la balise MemberShip, mais semble-t-il les mises en œuvre que j'en ai tentées jusque là ont échoué.

    L'histoire ne dit pas encore si c'est un petit truc tout bête qui va faire dire à tout le monde "ah mais oui bien sûr !", ou si il y a quelque chose de pas aussi orthodoxe que prévu, derrière, au niveau de l'installation. Le deuxième cas risque d'être plus coton que le premier à résoudre.

    ça peut être juste une histoire de casse. Au fait le nom du fournisseur par défaut, c'est AspNetMembershipProvider ?

    mercredi 2 juillet 2014 09:33
  • Avez-vous essaye de ajouter un Clear?

    <providers>
    <clear/>

      <add name="AspNetMembershipProvider".............................

    .................................

    Je dirais qu'il y a un erreur dans la config qui produit l'erreur.

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 2 juillet 2014 10:37
  • Oui j'ai mis un clear, de toute manière si il manque j'ai un message d'erreur clair dans ce sens (fournisseur déjà déclaré).

    On peut effectivement craindre une erreur de config, mais alors où chercher ...

    mercredi 2 juillet 2014 11:11
  • Pouvez-vous tester le code sur un autre ordinateur avec un autre SQL Serveur?

    J'ai peur qu'il y a un problème dans un fichier de config externe à votre application…

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 2 juillet 2014 12:05
  • C'est-à-dire que je vis dans une situation complètement surréaliste : j'ai cinq ans d'expérience sur la plate-forme .Net, j'ai automatisé le développement WCF, réalisé plusieurs développements sous MVC, fait aussi une période en client lourd sous C# avec support de la globalisation sur tous mes développements tant client lourd que site web, et ça ça intéresse beaucoup les recruteurs, surtout que là je n'ai pas parlé de mes atouts en dehors du contexte technique. Mais comme j'ai pratiqué ça dans le cadre de projets personnels, ça n'intéresse pas du tout leurs clients.

    Je prépare des sites génériques en guise de démonstration, mais à chaque fois que je m'occupe de relancer des candidatures ça repousse leur sortie du fait du temps à passer dessus. Je peux obtenir un financement pour une machine mais pas pour ma survie, donc sauf à trouver quelqu'un qui veuille bien me faire confiance sur ce que je sais bien faire, je cherche d'abord à tirer parti de mon expérience précédente, et là le marché n'est plus ce qu'il était.

    Donc là, pour manger au-delà de la semaine prochaine je me demande comment ça va se passer, alors forcément, acheter une machine ... Même modifier mon hébergement pour adjoindre SQL Server, du coup, j'hésite.

    Il y a déjà un fil d'optimisation où ça apparaissait de manière évidente comme une piste privilégiée.

    Le fichier de config externe à l'application s'appelle machine.config, si je me rappelle bien ?

    mercredi 2 juillet 2014 14:16
  • Oui, le fichier de config externe c'est machine.config.
    Pouvez-vous nous créer un petit projet de teste et le partager avec nous?
    J'aimerai voir comment ça se passé sur un autre ordinateur.

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 3 juillet 2014 08:21
  • Bonjour,

    OK je vais regarder ça, mais qu'est-ce que je mets dedans ?

    En fait Membership fonctionne très bien. C'est juste que de temps en temps, SQL Express est un peu long à démarrer. Parfois il suffit de l'avoir sollicité un peu avant le lancement de l'application en dépliant les nœuds de l'explorateur de serveurs.

    Hier soir ça ne suffisait pas, il fallait redémarrer Windows, en revanche ensuite SQL Server démarrait tout de suite sans aucun problème.

    Il faut dire que c'est une machine qui n'a que 1 Go de mémoire, de temps à autre il faut faire un peu de nettoyage si des processus parasites ont tendance à s'inviter.

    L'impression que ça donne c'est que parfois il y a des processus qui ne libèrent pas la mémoire, voire parfois qui n'ont rien à faire là, et que du coup la machine manque de ressources. Alors je redémarre et c'est reparti.

    Avant d'en arriver à être obligé de redémarrer, il y a un moment où SQL Express a un temps de réponse un peu long, mais si on insiste il finit par fonctionner -d'où l'idée d'allonger le timeout. En fait c'est ce qui se produit la plus grande partie du temps, entre quand je viens de démarrer Windows où SQL réagit tout de suite, et quand vraiment il n'y arrive plus et je dois redémarrer.

    jeudi 3 juillet 2014 10:06
  • Vérifiez SVP que vous fermez correctement les connexions vers la BD.
    Vous utilisez les instances utilisateur dans SQL - voir http://msdn.microsoft.com/fr-fr/library/ms254504(v=vs.110).aspx
    Essayez d'attacher la BD dans SQL Management Console, pour qu'elle soit visible dans SQL avec InitialCatalog et sans AttachDB.
    Pour cela vous devez modifier le string de connexion :
    Data Source=.\SQLEXPRESS;;Integrated Security=True;User Instance=False;InitialCatalog=NomBD;
    Comme ça, le système ne doit pas attacher la BD chaque fois.

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 3 juillet 2014 10:35
  • Voilà effectivement qui est particulièrement intéressant à plus d'un titre, et je crois même que je vais devoir y revenir à plusieurs fois pour en faire le tour.

    Quelques considérations en vrac pour commencer :

    • Le fichier de base de données dans le répertoire app_data est une configuration fréquemment proposée, et au demeurant elle a ceci de commode qu'elle est pratique à déployer
    • J'utilise effectivement les instances utilisateur, et je vois qu'alors qu'elles sont activées par défaut (voir machine.config), la fiche Microsoft dit que c'est en principe le contraire. Il a dû y avoir une option proposée quelque part, probablement pendant l'installation de SQL Express, car je soupçonne que si j'avais modifié ça à la main dans le machine.config je m'en souviendrais (bien qu'il soit difficile d'en jurer).
    • Je suis un peu surpris de la présentation faite des instances utilisateur, car depuis le début j'ai toujours pris soin d'ouvrir Visual Studio avec l'emprunt d'identité de l'administrateur pour avoir l'accès à la base de données. J'ai oublié deux ou trois fois de le faire, et ces deux ou trois fois je n'avais pas accès aux bases de données, que ce soit sur le serveur ou dans le répertoire app_data. Un point a donc dû m'échapper, car la fiche explique que les instances utilisateur ont pour but de dispenser de l'emprunt d'identité de l'administrateur.
    • Le message d'erreur lors de l'accès à la base varie, c'est parfois timeout expired, parfois impossible d'ouvrir (ou d'accéder à, me rappelle plus) le processus pour l'instance utilisateur. Je crois bien qu'il y a eu une troisième version aussi. Je pourrais copier plus de détails, mais il me semble que dans le cas du processus il est question de ressources machine. Dans tous les cas il est fréquent que F5 suivi de Entrée réussisse à établir la connexion, il arrive qu'il faille le faire plusieurs fois d'affilée, et en prenant garde entre les deux touches d'attendre que le disque finisse de mouliner.

    Je trouve ceci, ci après, dans machine.config, et je me dis que probablement c'est là que je serais bien inspiré de déclarer un timeout plus long : cette nécessité étant spécifique à la machine, ça paraît cohérent de le mettre là, non ? Sauf que cette chaîne de connexion est valable seulement pour Membership, donc ça fonctionnera à condition de s'authentifier avant d'accéder aux données de l'application.

    Au passage j'ai la réponse à la question que je me posais hier ou avant-hier : le fournisseur par défaut de Membership s'appelle AspNetSqlMembershipProvider.

      <connectionStrings>
        <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
        <add name="LocalMySqlServer" connectionString="" />
      </connectionStrings>
      <system.web>
        <processModel autoConfig="true" />
        <httpHandlers />
        <membership>
          <providers>
            <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="LocalSqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
            <add name="MySQLMembershipProvider" type="MySql.Web.Security.MySQLMembershipProvider, MySql.Web, Version=5.2.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Clear" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
          </providers>
        </membership>
        <profile>
          <providers>
            <add name="AspNetSqlProfileProvider" connectionStringName="LocalSqlServer" applicationName="/" type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            <add name="MySQLProfileProvider" type="MySql.Web.Profile.MySQLProfileProvider, MySql.Web, Version=5.2.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="/" />
          </providers>
        </profile>
        <roleManager>
          <providers>
            <add name="AspNetSqlRoleProvider" connectionStringName="LocalSqlServer" applicationName="/" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            <add name="AspNetWindowsTokenRoleProvider" applicationName="/" type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            <add name="MySQLRoleProvider" type="MySql.Web.Security.MySQLRoleProvider, MySql.Web, Version=5.2.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="/" />
          </providers>
        </roleManager>
      </system.web>
    

    jeudi 3 juillet 2014 13:26
  • Une fois que j'ai copié la balise (add name= ...) du MembershipProvider, depuis machine.config vers le Web.config de l'application, j'obtiens bien une balise valide, sous réserve de la précéder de clear ou remove pour éliminer celle de machine.config.

    Je peux aussi personnaliser la chaîne de connexion en la copiant vers le Web.config de l'application, à la même réserve, éliminer celle de machine.config par clear ou remove. D'ailleurs, ceci fait, la balise du MembershipProvider du machine.config fait l'affaire, la chaîne de connexion peut être cherchée dans le Web.config si elle porte le même nom.

    Donc, l'erreur semble-t-il est que je n'avais pas mis un type suffisamment précis, il manquait tout ce qui vient après la virgule.

    Une fois la chaîne de connexion récupérée dans le Web.config, j'ai pu jouer avec. J'ai remplacé SQLEXPRESS par SQLEssePRESS, et j'ai eu droit à une grosse injure pleine page, donc c'est bien cette chaîne de connexion qui était en œuvre. Au niveau du nom de base c'est moins catégorique. Dans la chaîne de connexion j'ai mis |DataDirectory|\Faux.mdb, et la connexion s'est faite. Dans le répertoire j'ai renommé ASPNETDB.MDF en AxPNETDB.MDF, là il ne faut pas exagérer, la connexion ne s'est pas faite. Dans le répertoire je me retrouvais avec AxPNETDB.MDF, ASPNETDB.MDF, et FAUX.MDF.

    Il semblerait donc que la plateforme cherche la base avec le nom indiqué dans la chaîne de connexion, si elle ne la trouve pas elle cherche ASPNETDB.MDF, et si elle ne la trouve pas non plus elle crée une base, ou les deux. Je n'ai pas poussé les investigations plus loin.

    La phase qui entre dans le vif du sujet, maintenant. A la fin de la chaîne de connexion j'ai ajouté ";Time out=120", et j'ai eu une page d'erreur avec  Time Out non reconnu. J'ai enlevé l'espace, plus d'erreur, connexion correcte.

    Je crois qu'on peut donc dire que la question du début du fil a sa réponse.

    Toutefois maintenant que j'ai mis un doigt dans l'histoire de la user instance, j'aimerais bien comprendre un peu plus, comme je disais quelques renseignements me paraissent contradictoires.


    • Modifié Gloops jeudi 3 juillet 2014 18:24
    • Marqué comme réponse Aurel Bera vendredi 4 juillet 2014 07:16
    jeudi 3 juillet 2014 18:18
  • Comme je disais dans mon message de 16h environ, j'ai lu aujourd'hui dans la doc que l'utilisation de user instance dispense d'avoir les droits de l'administrateur SQL Express pour ouvrir la base, or ce n'est pas ce que j'ai observé. Qu'est-ce que j'ai bien pu interpréter de travers ?

    Par ailleurs il y a cette histoire de fermeture de connexion à soigner.

    Quand j'écris un code pour ouvrir une connexion j'utilise toujours la syntaxe

    using (SqlConnexion cnx = new SqlConnexion)
    {
        cnx.Open();
    
        // ici utilisation
    
        cnx.Close();
    }
    
    

    Je n'ai pas toujours mis cnx.Close() d'ailleurs et il se peut que je ne l'aie pas mis partout, mais la doc confirme que ce n'est pas obligatoire.

    L'autre utilisation que je fais d'une connexion Sql c'est le contrôle Login.

    Qu'est-ce qui peut bien manquer ? Il est vrai que j'ai parfois un message signalant une difficulté à ouvrir une user instance, et qu'on peut soupçonner une instance mal fermée.

    jeudi 3 juillet 2014 18:34
  •  .  Le fichier de base de données dans le répertoire app_data est une configuration fréquemment proposée, et au demeurant elle a ceci de commode qu'elle est pratique à déployer

    Ah, oui, c'est vrai qu'on peut faire l'attache depuis SSMS plutôt que de laisser ASP.Net la faire au lancement de l'application. ça m'arrive d'ailleurs avec un projet sur lequel je suis pendant longtemps.

    Au demeurant, il y a aussi que c'est normal, dit la doc, d'avoir une connexion un peu plus longue à s'établir avec une user instance. Tant qu'à avoir deux inconvénients de la user instance, ça serait d'autant plus motivant d'en avoir les avantages, donc notamment de pouvoir lancer Visual Studio en profil Windows limité. Et de ne pas louper la fermeture pour qu'il soit facile de rouvrir la user instance.

    jeudi 3 juillet 2014 18:45
  • Normalement pour user instance = true on ne doit pas être administrateur. Voir cet article:
    http://technet.microsoft.com/fr-fr/library/ms143684(v=sql.105).aspx
    De l'autre cote, je soupçonne qu'on doit vérifier les droits de l'utilisateur sur la BD au les droits sur le fichier DB pour comprendre pourquoi l'user instance ne fonctionne pas en mode non administrateur.

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    vendredi 4 juillet 2014 07:26
  • Bonjour,

    C'est pourtant vrai. J'imagine que pour préciser davantage il faudra au besoin aller voir chez SQL server.

    C'est dommage, maintenant que je commence à comprendre à quoi sert la user instance je vois dans la doc que ça va bientôt être supprimé.

    Merci encore pour ces précieuses indications.

    vendredi 4 juillet 2014 07:48