7
votes

EF 4.1 Code Premier provoque des erreurs d'exécution bizarre (login)

J'utilise d'abord le code EF 4.1. Courir dans une situation très étrange: La base de données n'existe pas, le code est exécuté et dès que le code souhaite exécuter une requête contre le référentiel (en utilisant également le motif de référentiel) xxx

Je reçois cette erreur:

Impossible d'ouvrir la base de données "mydatabase" demandé par le login. Le login manqué. Login a échoué pour l'utilisateur 'SA'.

OK! J'ai donc essayé de trouver ce qu'il est causé par et que procédez comme suit: définir un point de rupture à la ligne qui a provoqué l'erreur et que cette ligne a été touchée, je suis sorti de la fenêtre de débogage (regarder) une autre requête contre le référentiel < / p> xxx

et voila La base de données est créée. Alors j'ai pensé: pourquoi ne pas tromper la base de données (en tant que solution de contournement) et émettre cette demande contre le référentiel? Le résultat: Je reçois la même erreur dès que cela est exécuté en code!

Qu'est-ce que je fais mal? Celui-ci fonctionnait comme un charme!

Modifier Cela me rend fou! J'ai isolé le modèle et certains code (pour le motif de référentiel) dans un nouveau projet. Essayé d'exécuter le même code et cela fonctionne dans ce nouveau projet. Comment cela est-ce possible?

regardé dans les journaux de SQL Serv2008 exp et je vois les erreurs / événements suivants:

Démarrage de la base de données de démarrage 'mydatabase'

Option de base de données unique_utilisateur sur la base de données MyDatabase.

Erreur: 18456, Gravité: 14, État: 38.

Login a échoué pour l'utilisateur 'SA'. Raison: Impossible d'ouvrir la base de données explicitement spécifiée. [Client:]


0 commentaires

3 Réponses :


1
votes

Par souci d'utilisation future: il s'avère que EF 4.1 n'était pas la source de mes problèmes!

Comme je l'ai dit ci-dessus (après la modification), il est possible d'exécuter le code (inchangé) dans un nouveau projet et il s'exécutera comme prévu!

Il est également vrai que j'ai créé avec succès un nouveau projet, référencé le modèle et les DAL (référentiels, etc.) du projet d'origine et le nouveau code dans le nouveau projet exécuté comme prévu.

Cela me conduise à penser qu'il s'agit d'une solution Visual Studio 2010 (ou d'un projet)-Based. Je ne me souviens pas de faire quoi que ce soit bizarre à cette solution (la seule chose que j'ai faite était d'ajouter un projet de test, que je suis ensuite supprimé, ainsi que certains - je pense que trois fichiers - liés à ce projet de test-projet - est-ce bizarre ?! ).

La seule solution à laquelle je pouvais penser, était de créer une nouvelle solution Visual Studio 2010 à partir de zéro et placez les projets d'origine dans l'arborescence de la solution ... et cela a fonctionné!


1 commentaires

J'ai fait face à un problème très similaire dans un projet d'API Web à VS 2015 aujourd'hui. Je n'ai pas eu de nouveau projet à partir de zéro. Au lieu de cela, j'ai fait une opération propre sur mon projet API Web C # de Solution Explorer et cela vient de travailler. C'est fou. Les mêmes informations d'identification SA (configurées dans le fichier web.config de mon projet fonctionnaient tout au long de la journée et cesserait soudainement de travailler hors de non où.



9
votes

Merci Savvas, pour partager le fait que la création d'une nouvelle solution résolvait votre problème. J'ai confronté la même question étrange avec EF 4.1 et la suppression du fichier VS2010 "Suo" semblait faire le tour pour moi. Je pensais que je partageais cela pour sauver les autres le temps de recréer la solution à partir de zéro.


4 commentaires

une idée de ce qui cause cela?


Je suis sur VS2012, aucun Suo dans ma solution du tout.


@Shimmy: Il devrait y en avoir un aussi même sur VS2012, non inclus dans la solution, mais à côté du fichier .sln et caché. Supprimer cela a résolu le problème.


J'ai fait face à un problème très similaire dans un projet d'API Web à VS 2015 aujourd'hui. Je n'ai supprimé aucun fichier * .suo explicitement comme je ne pouvais le voir. Il semble qu'ils ne présentent plus de * .suo fichier. Au lieu de cela, j'ai fait une opération propre sur mon projet API Web C # de Solution Explorer et cela vient de travailler. C'est fou. Les mêmes informations d'identification SA (configurées dans le fichier web.config de mon projet fonctionnaient tout au long de la journée et cesserait soudainement de travailler hors de non où.



1
votes

J'ai couru dans cela et après avoir creusé un peu d'avoir découvert que c'est un problème avec le code qui pensant que c'est le seul propriétaire du schéma.

http://social.msdn.microsoft.com/forums/fr/adonetefx/thread/79885A6D-E0f2-4948- 8F3C-D5DA1941ACE3 P>

Ils n'ont pas assez compris les instances utilisateur de la DB (c'est ici que 'Instance utilisateur = true' est dans votre chaîne de connexion et vous créez un fichier SQL Server dans votre Dossier App_Data). Donc, supprimez-le ou utilisez ce qui suit: p>

Data Source=.\SQLEXPRESS;Database=NerdDinners;Integrated Security=SSPI;


0 commentaires