Entity Framework avec MySQL - Délai d'attente expiré alors que Génération Modèle

Question

Je l'ai construit une base de données MySQL et je tente de mapper avec Entity Framework, mais je commence à courir dans l « GenerateSSDLException » chaque fois que j'essaie d'ajouter plus d'environ 20 tableaux au contexte EF.

  

Une exception de type   'Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.Engine.ModelBuilderEngine + GenerateSSDLException'   lors de la tentative de mise à jour   de la base de données. L'éxéption   message est: « Une erreur est survenue lors   l'exécution de la définition de la commande. Voir   l'exception interne pour plus de détails.

     

Erreur fatale rencontrée lors de l'exécution de la commande.

     

Délai d'attente expiré. Le délai d'attente écoulé avant la fin de l'opération ou le serveur ne répond pas.

Il n'y a rien de spécial les tables concernées, et il n'y a jamais la même table (s), il est juste que, après un certain (non spécifique) nombre de tables ont été ajoutés, le contexte ne peut plus être mis à jour sans le « délai d'attente a expiré » Erreur. il est parfois qu'une seule table reste, et parfois il est trois; les résultats sont assez imprévisibles. En outre, la variance du nombre de tableaux qui peuvent être ajoutés avant que l'erreur me indique peut-être le problème réside dans la taille de la requête générée de manière à mettre à jour le contexte qui comprend à la fois les définitions de tables existantes, ainsi que les nouvelles tables sont ajoutés. Essentiellement, la requête SQL devient trop grand et il défaut d'exécution pour une raison quelconque.

Si je produis le modèle avec EdmGen2 cela fonctionne sans erreur, mais le fichier généré EDMX ne peut pas être mis à jour dans Visual studio sans produire l'exception mentionnée ci-dessus.

Selon toute vraisemblance, la source de ce problème réside dans l'outil dans Visual Studio étant donné que EdmGen2 fonctionne très bien, mais je suis en espérant que peut-être d'autres pourraient offrir quelques conseils sur la façon d'aborder cette question tout à fait unique, car il semble que < a href = "http://forums.mysql.com/read.php?38,285936,285936" rel = "noreferrer"> Je ne suis pas la seule personne éprouvant .

Une suggestion d'un collègue a proposé maintenait deux fichiers séparés EBMX avec un certain crossover table, mais qui semble comme une solution assez laid à mon avis. Je suppose que ce que je reçois pour essayer d'utiliser « nouvelles technologies ». : (

Answer 1

Je viens d'avoir des maux de tête sur ce problème dans l'ensemble de l'après-midi. Cependant, j'ai trouvé la solution que vous pouvez simplement ajouter une déclaration dans app.config ou web.config où votre connexion EF desinger existe en tant que « défaut de commande Délai d'attente = 300000; ». Le problème a disparu.

Answer 2

Les conseils ci-dessus est incorrect.

Default Command Timeout est le seul paramètre de chaîne de connexion que vous devez changer. Connect Time régule tout le temps d'attendre pour obtenir une connexion en premier lieu; ce n'est pas votre problème.

Default Command Timeout semble avoir aucun effet dans la chaîne de connexion avec connecteur / Net 6.3.4. Je pense que ce bogue dans connecteur / Net, et je déposé un avec Oracle. EDIT: Ce bug a été reconnu par les développeurs MySql et a été fixée au 10/13/2010. Corrections ont été mises en 6.0.8, 6.1.6, 6.2.5 et 6.3.5.

La seule façon dont je suis cela était de changer mon objet ObjectContext propriété de la CommandTimeout autre chose que nul. Si elle est nulle, il est censé utiliser la valeur dans le « fournisseur sous-jacent » par MSDN. Si non nul, il est la valeur autorisée pour le nombre de secondes avant un délai d'attente.

Par exemple:

var context = new CitationData.de_rawEntities();
context.CommandTimeout = 180;

Answer 3

Départ:

http: // efvote. wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Oops, juste rendu compte que ce lien était déjà affiché! désolé

Je voudrais aussi envisager sérieusement « Une suggestion d'un collègue a proposé maintenait deux fichiers séparés EBMX avec un certain crossover table »

Il peut être laid, mais il devrait fonctionner!

Answer 4

gars Vous êtes faible pour ne pas expliquer comment résoudre le problème facilement:

1. Supprimer toutes vos connexions de données
2. Téléchargez la dernière MySql Connecteur (6.3.x)
3. Ouvrez Visual Studio> Sever Explorateur> Clic droit "Connexions de données"> Ajouter une connexion
4. Choisissez MySQL fournisseur de base de données
5. Entrez les détails de connexion
6. Cliquez sur "Advance"
7. Trouver Connect Time out et faire quelque chose comme 30 000
8. Rechercher Délai d'attente de commande par défaut et faire quelque chose comme 30 000

Enregistrer tout et puis essayer de mettre à jour votre modèle EF à nouveau. Je l'ai testé cela avec EF 4.0 et VS2010 donc je sais que cela fonctionne.

Answer 5

J'ai essayé toute la solution ci-dessus en vain. J'ai téléchargé le dernier connecteur .NET pour MySQL (6.3.6) et le problème a disparu.

Answer 6

dotConnect pour MySQL avec développeur entité .
Nous avons apporté quelques améliorations dans le processus de génération de modèle dans nos outils. Vous pouvez ajouter le modèle d'entité Devart à votre projet, qui est similaire au modèle ADO.NET Entity Framework, mais a quelques améliorations et n'a pas le problème de délai d'attente.

Answer 7

Deux possibilités viennent à l'esprit:

La première est que c'est la version EF 1 (qui livré avec .NET 3.5 SP 1). Voir cette et cette .

L'autre est que cela se sent à peu près comme les mêmes symptômes On avait avec SQL Server et les pilotes pré-ODBC (vers 1991) où le type d'appel mal a été utilisé: un type est utilisé avec des requêtes résultats retour (select), et l'autre pour les états-ne pas retourner un résultat (create table). Finalement, la connexion est devenu désespérément désynchronisé essayer de faire correspondre les résultats SELECT à la requête correspondante. (Dans ces jours, le écran bleu de la mort n'existait pas:. L'ordinateur avait tendance à redémarrer volontairement à la place)

Je me demande si l'outil confond le mode de connexion dans la variété des opérations en cours d'exécution: la création de tableaux, la vérification de la structure créée, l'ajout d'une nouvelle colonne, peuplant les lignes, et la vérification ou la validation du contenu de la ligne après avoir été rempli. Si cela est la cause, alors il pourrait être évité en étant plus « purs » de la séquence d'opérations: ne rien faire mais le tableau complet crée un après l'autre qui est, ne rien faire qui amèneraient pour créer une table alter table puis d'ajouter de nouvelles colonnes.