gcaprio
gcaprio

Reputation: 6787

"Specified cast is not valid" error when saving LINQ-To-SQL entity

App Details: C#, ASP.NET MVC, SQL Server 2008 ( Same version & SP level), Linq-To-SQL ORM

I'm trying to diagnose an exception I'm receiving:

"Specified cast is not valid." at System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManage`2.TryCreateKeyFromValues(Object[] values, V& v)
at System.Data.Linq.IdentityManager.StandardIdentityManager.IdentityCache`2.Find(Object[] keyValues)
at System.Data.Linq.IdentityManager.StandardIdentityManager.Find(MetaType type, Object[] keyValues)
at System.Data.Linq.CommonDataServices.GetCachedObject(MetaType type, Object[] keyValues)
at System.Data.Linq.ChangeProcessor.GetOtherItem(MetaAssociation assoc, Object instance)
at System.Data.Linq.ChangeProcessor.BuildEdgeMaps()
at System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges()
at Repository.Save() at etc....

The problem is that this is occurring only on our servers, not on our local development boxes. I've tracked it down to a single property we're modifying:

event.SalesForceId = "701Q0000000AOTIIA4";

If I comment out that line, everything works fine.

I've tried:

1 ) waxing all of the code on the server and redeploying. Same issue.
2 ) Pulling down a copy of the server DB and trying it locally. Works fine.
3 ) Trying another IIS environment we have setup on the same box. Same issue.
4 ) Physically comparing ( using AdeptSQL ) both local and remote schemas. No differences.
5 ) Verifying the datatypes of both columns ( local and remote ) are the same. Also, this column is a FK to another table. I verified that both are of the same data type, down to the collation.

The server is Windows Server 2008 and the local box is Windows 7 x64. Both have all important updates setup.

The only thing I can think of is perhaps since the database and web server are on different boxes that could be an issue? Otherwise, I'm completely stumped.

Any ideas?

Upvotes: 5

Views: 5252

Answers (2)

user166390
user166390

Reputation:

If that key exists in a defined relationship and the object is already created then the LINQ-provided relationship path (obj.Foo = new Foo { ... }) must be used. (I would use the provided relationships even for new objects). Failure to do so will result -- speaking from experience -- in "random" errors like that.

Another issue that can cause that (or a very similar error) is reversed relationship columns, for compound relationships. However, if the generated code is the same and the DB is the same (for real, on both accounts) then I suspect the first reason is the culprit.

Happy SQL-to-LINQ pothole jumping.

Upvotes: 1

Related Questions