Below is my connection string:
connectionString=\"metadata=res://*/EDMX.Test.csdl|res://*/EDMX.Test.ssdl|res://*/EDMX.Test.msl;provider=System.Data.Sq
I faced the same issue. Though in my case I was trying to connect my desktop application to a remote db. So for me, all the above didn't work. I solve this problem by just adding the port (as 128.02.39.29:3315
) and it magically works!
The reason why I didn't bother to add the port in the first place is because I used same approach (without the port) in another desktop app and it worked.
So I hope this might help someone as well.
ERROR : An exception of type 'System.Data.Entity.Core.EntityException' occurred in EntityFramework.SqlServer.dll but was not handled in user code Additional information: The underlying provider failed on Open.
SOLUTION:
Add in Model:
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
[Key]
Namespace:
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
Example:
namespace MvcApplication1.Models
{
[Table("tblEmployee")]
public class Employee
{
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
[Key]
public int EmplyeeID { get; set; }
public string Name { get; set; }
public string Gender { get; set; }
public string City { get; set; }
}
}
Seems like a connection issue. You can use the Data link properties to find if the connection is fine. Do the following:
Now open the file in Notepad and compare the connection string properties.
I get this exception often while running on my development machine, especially after I make a code change, rebuild the code, then execute an associated web page(s). However, the problem goes away for me if I bump up the CommandTimeout parameter to 120 seconds or more (e.g., set context.Database.CommandTimeout = 120 before the LINQ statement). While this was originally asked 3 years ago, it may help someone looking for an answer. My theory is VisualStudio takes time to convert the built binary libraries to machine code, and times out when attempting to connect to SQL Server following that just-in-time compile.
I got this problem while continuing execution of a unit test that calls a method that is using parallel processing.I know there are parts of EF that are not thread-safe, so I am wondering if it is a conflict where the connection is being open and closed out of sync with the operations.
My stack trace showed this:
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at System.Threading.Tasks.Parallel.ForWorker[TLocal](Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Func`4 bodyWithLocal, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IList`1 list, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, Action`1 body)
So that's the clue I followed. When I went back to a single-thread foreach instead of Parallel.ForEach the issue went away.
Joey
I saw this error when a colleague was trying to connect to a database that was protected behind a VPN. The user had unknownling switched to a wireless network that did not have VPN access. One way to test this scenario is to see if you can establish a connection in another means, such as SSMS, and see if that fails as well.