使用 MySQL 的实体框架 - 生成模型时超时已过期
我已经在 MySQL 中构建了一个数据库，并尝试使用实体框架将其映射出来，但每当我尝试向 EF 上下文添加大约 20 个以上的表时，我就会开始遇到“GenerateSSDLException”。
类型异常 'Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.Engine.ModelBuilderEngine+GenerateSSDLException' 尝试更新时发生 从数据库中。例外情况 消息是：“发生错误 执行命令定义。看 内部异常的详细信息。'
命令执行期间遇到致命错误。
超时已过。操作完成之前超时时间已过，或者服务器没有响应。
受影响的表没有什么特别之处，而且从来都不是相同的表，只是在添加一定数量（非特定）的表后，无法再在没有“超时已过期”错误的情况下更新上下文。有时只剩下一张桌子，有时则只剩下三张桌子；结果是很难预测的。此外，在错误发生之前可以添加的表数量的差异向我表明，问题可能在于为更新上下文而生成的查询的大小，其中包括现有的表定义以及新表。正在被添加到其中。本质上，SQL 查询变得太大并且由于某种原因无法执行。
如果我使用 EdmGen2 生成模型，它可以正常工作，没有任何错误，但生成的 EDMX 文件无法更新在 Visual Studio 中，不会产生上述异常。
鉴于 EdmGen2 工作正常，这个问题的根源很可能在于 Visual Studio 中的工具，但我希望其他人可以就如何解决这个非常独特的问题提供一些建议，因为它看起来像 我不是唯一经历过这种情况的人。
一位同事提出的一个建议是维护两个独立的 EBMX 文件，并进行一些表交叉，但在我看来，这似乎是一个相当丑陋的修复。我想这就是我尝试使用“新技术”所得到的结果。 :(
I've constructed a database in MySQL and I am attempting to map it out with Entity Framework, but I start running into "GenerateSSDLException"s whenever I try to add more than about 20 tables to the EF context.
An exception of type
'Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.Engine.ModelBuilderEngine+GenerateSSDLException'
occurred while attempting to update
from the database. The exception
message is: 'An error occurred while
executing the command definition. See
the inner exception for details.'Fatal error encountered during command execution.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
There's nothing special about the affected tables, and it's never the same table(s), it's just that after a certain (unspecific) number of tables have been added, the context can no longer be updated without the "Timeout expired" error. Sometimes it's only one table left over, and sometimes it's three; results are pretty unpredictable. Furthermore, the variance in the number of tables which can be added before the error indicates to me that perhaps the problem lies in the size of the query being generated to update the context which includes both the existing table definitions, and also the new tables that are being added to it. Essentially, the SQL query is getting too large and it's failing to execute for some reason.
If I generate the model with EdmGen2 it works without any errors, but the generated EDMX file cannot be updated within Visual Studio without producing the aforementioned exception.
In all likelihood the source of this problem lies in the tool within Visual Studio given that EdmGen2 works fine, but I'm hoping that perhaps others could offer some advice on how to approach this very unique issue, because it seems like I'm not the only person experiencing it.
One suggestion a colleague offered was maintaining two separate EBMX files with some table crossover, but that seems like a pretty ugly fix in my opinion. I suppose this is what I get for trying to use "new technology". :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我整个下午都为这个问题头疼。但是，我找到了解决方案，您只需在 app.config 或 web.config 中添加一条语句，其中您的 EF 设计器连接存在为“默认命令超时 = 300000;”。问题就消失了。
I just had headache on this problem in the whole afternoon. However, I found the solution that you can just add a statement in app.config or web.config where your EF desinger connection exists as 'Default Command Timeout=300000;'. The problem's gone.
上述建议并不正确。
Default Command Timeout是您需要更改的唯一连接字符串参数。Connect Time只是调节首先等待获得连接的时间；那不是你的问题。默认命令超时似乎对 Connector/Net 6.3.4 的连接字符串没有影响。我认为这是 Connector/Net 中的错误，我提交了 错误报告 与甲骨文。 编辑：此错误已被 MySql 开发人员承认，并已于 2010 年 10 月 13 日修复。 6.0.8、6.1.6、6.2.5 和 6.3.5 中进行了修复。解决此问题的唯一方法是更改
ObjectContext对象的CommandTimeout< /code> 属性为除 null 之外的其他内容。如果它为空，则应该使用 MSDN 中“底层提供程序”中的值。如果不为空，则它是超时前秒数的权威值。例如：
The above advice is not correct.
Default Command Timeoutis the only connection string parameter you need to change.Connect Timejust regulates the amount of time to wait to get a connection in the first place; that is not your problem.Default Command Timeoutappears to have no effect in the connection string with Connector/Net 6.3.4. I think this is a bug in Connector/Net, and I filed a bug report with Oracle. EDIT: This bug was acknowledged by MySql developers and has been fixed as of 10/13/2010. Fixes were put in 6.0.8, 6.1.6, 6.2.5, and 6.3.5.The only way I got around this was to change my
ObjectContextobject'sCommandTimeoutproperty to something other than null. If it's null, it's supposed to use the value in the "underlying provider" per MSDN. If not null, it is the authoritative value for number of seconds before a timeout.For example:
查看：
http://efvote。 wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
哎呀，刚刚意识到这个链接已经发布了！抱歉，
我也会强烈考虑“一位同事提出的一个建议是维护两个单独的 EBMX 文件并进行一些表交叉”
它可能很难看，但它应该可以工作！
Check out:
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
Oops, just realised that this link was already posted! sorry
I would also strongly consider "One suggestion a colleague offered was maintaining two separate EBMX files with some table crossover"
It may be ugly, but it should work!
你们很弱，没有解释如何轻松解决问题：
保存所有内容，然后再次尝试更新 EF 模型。我用 EF 4.0 和 Vs2010 对此进行了测试，所以我知道它有效。
You guys are weak not explaining how to fix the problem easily:
Save everything and then try and update your EF model again. I tested this with EF 4.0 and Vs2010 so I know it works.
我尝试了以上所有解决方案均无济于事。我下载了最新的 MySQL .NET 连接器 (6.3.6)，问题就消失了。
I tried all of the above solution to no avail. I downloaded the latest .NET connector for MySQL (6.3.6) and the problem disappeared.
尝试 dotConnect for MySQL 与 实体开发人员。
我们对工具中的模型生成过程进行了一些改进。您可以将 Devart 实体模型添加到您的项目中，它与 ADO.NET 实体框架模型类似，但有一些改进并且不存在超时问题。
Try dotConnect for MySQL with Entity Developer.
We have made some improvements in the model generation process in our tools. You can add the Devart Entity Model to your project, which is similar to the ADO.NET Entity Framework model, but has some improvements and does not have the timeout problem.
我想到了两种可能性：
第一种是它是 EF 版本 1（随 .NET 3.5 SP 1 一起提供）。请参阅此和这个。
另一个是，这感觉与 SQL Server 和 ODBC 之前的驱动程序（大约 1991 年）遇到的症状大致相同，其中使用了错误的调用类型：一种用于返回结果的查询（
select)，另一个 for 语句 - 不返回结果 (create table)。最终，在尝试将 SELECT 结果与相应查询匹配时，连接变得无可救药地不同步。 （在那些日子里，蓝屏死机并不存在：计算机倾向于自动重新启动。）我想知道该工具是否在执行的各种操作中混淆了连接模式：创建表，验证创建的结构，添加新列，填充行，并在填充后验证或确认行内容。如果这是原因，那么可以通过对操作顺序进行“更纯粹”来避免：除了完成一个又一个的表创建之外，什么都不做，也就是说，不做任何会导致它创建一个表然后更改的事情table 添加新列。
Two possibilities spring to mind:
First is that it is EF version 1 (which shipped with .NET 3.5 SP 1). See this and this.
The other is that this feels roughly like the same symptoms one got with SQL Server and pre-ODBC drivers (circa 1991) where the wrong type of call was used: one kind is used with queries returning results (
select), and the other for statements—not returning a result (create table). Eventually the connection became hopelessly unsynchronized trying to match up SELECT results to the corresponding query. (In those days, the Blue Screen Of Death didn't exist: the computer tended to reboot voluntarily instead.)I wonder if the tool is confusing the connection mode in the variety of operations being performed: creating tables, verifying the created structure, adding a new column, populating rows, and verifying or validating the row content after being filled. If this is the cause, then it might be averted by being "purer" about the sequence of operations: do nothing but complete table creates one after another—that is, do nothing which would cause it to create a table then
alter tableto add new columns.