使用 SQL Server 2008 和 SQL Server 2005 以及日期时间
我已经根据 2008 年数据库构建了一个实体框架模型。 2008 年数据库一切正常。 当我尝试更新 2005 数据库上的实体时,出现此错误。
The version of SQL Server in use does not support datatype 'datetime2
我在构建数据库时特别没有使用任何 2008 年的功能。 我在代码中找不到任何对 datetime2 的引用。 并且,是的,该列在数据库中定义为“日期时间”。
I've built a entity framework model against a 2008 database. All works ok against the 2008 database. When I try to update the entity on a 2005 database I get this error.
The version of SQL Server in use does not support datatype 'datetime2
I specifically did not use any 2008 features when I built the database. I can't find any reference to datetime2 in the code. And, yes the column is defined as "datetime" in the database.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
快速谷歌将我指向看起来像解决方案。
在文件编辑器中打开 EDMX(或在 Visual Studio 中“打开方式...”并选择 XML 编辑器)。 在顶部,您将找到存储模型,它有一个属性 ProviderManifestToken。 它的值应该是 2008。将其更改为 2005,重新编译,一切正常。
注意:每次从数据库更新模型时都必须执行此操作。
A quick google points me to what looks like the solution.
Open your EDMX in a file editor (or “open with…” in Visual Studio and select XML Editor). At the top you will find the storage model and it has an attribute ProviderManifestToken. This has should have the value 2008. Change that to 2005, recompile and everything works.
NOTE: You'll have to do this every time you update the model from database.
线路快速查看:
Quick view of line:
这是非常令人沮丧的,我很惊讶微软决定不这样做,这样你就可以针对给定的 SQL 版本。 为了确保我们的目标是 2005 年,我编写了一个简单的控制台应用程序并在 PreBuild 步骤中调用它。
预构建步骤如下所示:
代码在这里:
This is very frustrating and I am surprised MS decided not to make it so you could target a given SQL version. To make sure we are targeting 2005 I wrote a simple console app and call it in a PreBuild step.
The prebuild step looks like this:
The code is here:
使用上面@Vance 的便捷控制台应用程序,我使用以下内容作为 BeforeBuild 事件
这非常方便,因为避免了烦人的重新部署。 感谢分享 Vance。
我已将 TF.exe 添加到库解决方案文件夹中,这很有帮助,因为我现在可以在尝试编辑 edmx 文件之前检查它们,作为构建的一部分。 另外,我还添加了条件,以便将部署到服务器的设置设置为 2005,将开发计算机 sln 配置设置为 2008。 还要提一下,您需要将实际的 SetEdmxSqlVersion.exe(和 .pdb)文件添加到 Library 文件夹(或您想要保留这些位的其他位置)。
非常感谢@Vance。非常简洁,节省大量时间,并使我的构建完全自动化且无痛:)
Using @Vance's handy console app above, I used the following as a BeforeBuild event
This is super handy, as avoids annoying redeployment. Thanks for sharing Vance.
I've added TF.exe to the Library solution folder and this helps, as I can now check out the edmx files before trying to edit them, as part of the build. Also I have added this with conditions, so that it sets to 2005 for deployments to the server and back to 2008 for the Dev machine sln configurations. Also to mention you need to add the actual SetEdmxSqlVersion.exe (and .pdb) file(s) to the Library folder (or wherever else you want to keep these bits).
Thanks very much @Vance. Really neat, massive time saver and keeps my builds totally automated and pain free :)
2012 年与 2008 年有类似的问题。它可以通过使用 XmlPeek 和 XmlPoke 的 BeforeBuild 事件来解决:
如果您不喜欢自动替换,您可以简单地将 XmlPoke 任务替换为 Error 任务。
Had a similar problem with 2012 vs. 2008. It can be solved with a BeforeBuild event using XmlPeek and XmlPoke:
If you dislike automated replacement, you can simply replace the XmlPoke task with an Error task.
为了使遇到相同问题但使用Code First的人受益,请查看我的答案 a> 有关如何更改 Code First 中的
ProviderManifestToken
的信息。 它涉及在调用模型构建器的Build
方法时手动创建DbModelBuilder
并传递DbProviderInfo
实例(带有适当的令牌)。For the benefit of people who encounter the same issue but are using Code First, check out my answer here about how to change the
ProviderManifestToken
in Code First. It involves creating aDbModelBuilder
manually and passing aDbProviderInfo
instance (with the appropriate token) when calling the model builder'sBuild
method.对我来说更好的解决方案是在设计模式下和上下文菜单“从数据库更新模型...”中打开 edmx,而不是手动编辑 EDMX 文件。
当然,无论这适合您,您都必须指向正确的 SQL 版本。
Better solution to me is instead of manually editing EDMX file is just open edmx in design mode and in context menu "Update Model from Database...".
You have to be pointing to right SQL version of course whatever this is for you.
我们在 SQL2005 v.3 上遇到此错误,而在 SQL2005 v.4 上则没有此错误。
将 SQL2005 添加到连接字符串解决了我们的特定问题。
我们尚未确定原因,并且不想修改代码以提供上面解决的令牌(部署期间出现的问题)。
We had this error on SQL2005 v.3, where we did not have it on SQL2005 v.4.
Adding SQL2005 to the connection string fixed our specific problem.
We haven't identified why yet, and did not want to modify code to provide the token as solved above (issue manifested during deployment).