Domanda

Two questions, followed by details:

  1. What other side effects occur when I change my ProviderManifestToken to "2005"?
  2. Is it unwise to make the schema change in the database from datetime to datetime2? For instance, if I leave my ProviderManifestToken as "2008" and someone later tries to generate the database schema from the EDMX model, will it use datetime2 datatype for these columns when it creates them?

Details:

VS2010 SP1
.NET 4
EF 4
SQL Server 2008

I have no hands-on Entity Framework experience, and I'm suddenly maintaining a codebase which uses it. The codebase is brittle, on a tight schedule, and not yet well understood by those who remain.

Solution Explorer shows an EDMX file which maps to an existing schema in our DEV database. I don't know which (the model or the database) came first.

A commit operation is failing with this error:

The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.

When I look at the datatypes of my date/time columns in my SQL Server 2008 instance, they're all datetime, not datetime2.

When I look at the XML of the EDMX file, I see this Schema element attribute:

ProviderManifestToken="2008"

I'm guessing that, somewhere, there's a DateTime value in my .NET code which has a value outside the range of SQL Server 2008's datetime datatype. I've gathered from reading that changing the EDMX's ProviderManifestToken to "2005" would prevent EF from trying to use the datetime2 type during these commits.

Here's my problem: I don't know what else about this codebase, or EF's place in it, will change if I change this from 2008 to 2005, and I have a bias against moving backwards with technology when it's not absolutely required.

È stato utile?

Soluzione

There are some things what would indeed no longer function by changing the ProviderManifestToken to 2005. Specifically, LINQ queries that use functions related to the SQL 2008 time type. I personally haven't had a problem by changing the token to 2005 (even on a per-environment basis across multiple environments)...but it isn't something to be taken lightly. You'll need to thoroughly test all queries in your application.

As for the schema generated by the edmx in the reverse direction - that's determined by the SQL generation template associated with your edmx, not the ProviderManifestToken itself.

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