Domanda

Ho costruito un database in MySQL e sto cercando di mappare fuori con Entity Framework, ma io comincio a correre in s "GenerateSSDLException" ogni volta che provo ad aggiungere più di circa 20 tavoli al contesto EF.

  

Un'eccezione di tipo   'Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.Engine.ModelBuilderEngine + GenerateSSDLException'   durante il tentativo di aggiornare   dal database. L'eccezione   messaggio è: 'verificato un errore durante   eseguendo la definizione di comando. Vedere   l'eccezione interna per i dettagli '.

     

Fatal error incontrato durante l'esecuzione del comando.

     

Timeout scaduto. Il periodo di timeout trascorso prima del completamento dell'operazione o il server non risponde.

Non c'è niente di speciale circa le tabelle interessate, e non è mai la stessa tabella (s), è solo che dopo sono stati aggiunti un certo (non specifica) numero di tabelle, il contesto non può più essere aggiornato senza il "timeout" errore. A volte è solo una tabella a sinistra sopra, ed a volte è tre; i risultati sono piuttosto imprevedibili. Inoltre, la varianza del numero di tabelle che possono essere aggiunti prima dell'errore segnala me che forse il problema risiede nella dimensione della query generato per aggiornare il contesto che comprende sia le definizioni di tabella esistenti, e anche le nuove tabelle vengono aggiunti ad esso. In sostanza, la query SQL sta diventando troppo grande ed è non riuscendo ad eseguire per qualche ragione.

Se ho generare il modello con EdmGen2 funziona senza errori, ma il file generato EDMX non può essere aggiornato all'interno di Visual Studio senza produrre l'eccezione di cui sopra.

Con ogni probabilità la fonte di questo problema sta nello strumento all'interno di Visual Studio dato che EdmGen2 funziona bene, ma spero che forse altri potrebbero offrire alcuni consigli su come affrontare questo problema molto particolare, perché sembra che < a href = "http://forums.mysql.com/read.php?38,285936,285936" rel = "noreferrer"> io non sono l'unica persona sperimentandola .

Un suggerimento di un collega ha offerto è stato il mantenimento di due file EBMX separati con qualche tavolo di crossover, ma che sembra un abbastanza brutto correzione a mio parere. Suppongo che questo è ciò che ottengo per aver tentato di usare "nuova tecnologia". : (

È stato utile?

Soluzione

Ho appena avuto mal di testa su questo problema in tutto il pomeriggio. Tuttavia, ho trovato la soluzione che si può semplicemente aggiungere una dichiarazione in app.config o web.config in cui è presente la connessione a desinger EF come 'Command timeout predefinito = 300000;'. Il problema è andato.

Altri suggerimenti

Il consiglio di cui sopra non è corretto.

Default Command Timeout è l'unico parametro stringa di connessione è necessario cambiare. Connect Time solo regola la quantità di tempo di attesa per ottenere una connessione, in primo luogo; che non è il vostro problema.

Default Command Timeout sembra non avere alcun effetto nella stringa di connessione con Connector / Net 6.3.4. Penso che questo sia un bug in Connector / Net, e ho presentato un con Oracle. EDIT: Questo problema è stato riconosciuto dagli sviluppatori MySql ed è stato fissato a partire dal 10/13/2010. Le correzioni sono stati messi in 6.0.8, 6.1.6, 6.2.5, 6.3.5 e.

L'unico modo che ho avuto intorno a questo è stato quello di modificare la proprietà ObjectContext del mio oggetto CommandTimeout a qualcosa di diverso da null. Se si tratta di nulla, si suppone di utilizzare il valore del "provider sottostante" per MSDN. Se non nullo, è il valore autorevole per numero di secondi prima di un timeout.

Ad esempio:

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

Check out:

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

Ops, appena si rese conto che questo collegamento è stato già pubblicato! scusate

Vorrei anche prendere in seria considerazione "Un suggerimento di un collega ha offerto manteneva due file EBMX separati con qualche tavolo di crossover"

Può essere brutto, ma dovrebbe funzionare!

Voi ragazzi siete debole non spiega come risolvere il problema facilmente:

  1. Elimina tutte le connessioni dati
  2. Scarica l'ultima MySQL Connector (6.3.x)
  3. Aprire Visual Studio> Sever Explorer> tasto destro "Connessioni dati"> Aggiungi connessione
  4. Scegli MySQL provider di database
  5. Inserire i dettagli di collegamento
  6. Fare clic su "Advance"
  7. Trova Collegare Time out e renderlo qualcosa come 30.000
  8. Trova predefinita del timeout di comando e renderlo qualcosa come 30.000

Salva tutto e poi cercare di aggiornare nuovamente il proprio modello EF. Ho provato questo con EF 4.0 e VS2010 quindi so che funziona.

Ho provato tutta la soluzione di cui sopra senza alcun risultato. Ho scaricato il connettore .NET più recente per MySQL (6.3.6) e il problema è scomparso.

dotConnect per MySQL con Developer entità .
Abbiamo fatto alcuni miglioramenti nel processo di modello di generazione nei nostri strumenti. È possibile aggiungere il Devart Entity Model per il progetto, che è simile al modello ADO.NET Entity Framework, ma ha alcuni miglioramenti e non ha il problema di timeout.

Due possibilità in mente:

Il primo è che si tratta di EF la versione 1 (che fornito con .NET 3.5 SP 1). Vedere questo e questo .

L'altra è che questo si sente più o meno come gli stessi sintomi si è fatto con SQL Server e driver pre-ODBC (circa 1991), dove è stato utilizzato il tipo sbagliato di chiamata: un tipo è usato con le query di restituire i risultati (select), e l'altra per le dichiarazioni, non restituisce un risultato (create table). Alla fine, il collegamento è diventato irrimediabilmente non sincronizzato cercando di abbinare risultati SELECT al corrispondente query. (In quei giorni, il Blue Screen of Death non esistevano:. Il computer tende a riavviare volontariamente invece)

Mi domando se l'utensile confonde la modalità di connessione nella varietà di operazioni eseguite: creazione di tabelle, verificando la struttura creata, l'aggiunta di una nuova colonna, popolamento righe e verifica o convalida il contenuto fila dopo il riempimento. Se questa è la causa, allora potrebbe essere evitato con l'essere "più puro" per la sequenza di operazioni: non fare nulla, ma tabella completa crea uno dopo l'altro, cioè non fare nulla che causerebbe per creare un tavolo allora alter table per aggiungere nuove colonne.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top