O PROVEDOR SUBJACENTE FALHOU EM OPEN.
Boa Noite a todos.
Estou com um problema que quase estou perdendo os cabelos para solucionar.
Faço a minha conexão via web.config.
Porem quando vou salvar na base de dados me aparece um erro assim
O provedor subjacente falhou em Open.
aqui esta minha string de conexão
<connectionStrings>
<add name=[Ô]ApplicationServices[Ô] connectionString=[Ô]data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true[Ô] providerName=[Ô]System.Data.SqlClient[Ô]/>
<add name=[Ô]conPAG[Ô] connectionString=[Ô]metadata=res://*/PAGAMENTO.csdl|res://*/PAGAMENTO.ssdl|res://*/PAGAMENTO.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.\SQLEXPRESS;Initial Catalog=MOC;MultipleActiveResultSets=True"[Ô] providerName=[Ô]System.Data.EntityClient[Ô] />
</connectionStrings>
alguem poderia me ajudar por favor.
Estou com um problema que quase estou perdendo os cabelos para solucionar.
Faço a minha conexão via web.config.
Porem quando vou salvar na base de dados me aparece um erro assim
O provedor subjacente falhou em Open.
aqui esta minha string de conexão
<connectionStrings>
<add name=[Ô]ApplicationServices[Ô] connectionString=[Ô]data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true[Ô] providerName=[Ô]System.Data.SqlClient[Ô]/>
<add name=[Ô]conPAG[Ô] connectionString=[Ô]metadata=res://*/PAGAMENTO.csdl|res://*/PAGAMENTO.ssdl|res://*/PAGAMENTO.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.\SQLEXPRESS;Initial Catalog=MOC;MultipleActiveResultSets=True"[Ô] providerName=[Ô]System.Data.EntityClient[Ô] />
</connectionStrings>
alguem poderia me ajudar por favor.
Não encontrei problemas aparentes no código.
Repare, todavia, que a conexão requer que você esteja executando seu projeto em sua máquina local ou em uma intranet com ActiveDirectory ([Ô]Integrated Security=SSPI[Ô]) e suporte á SQL Server Express no modelo Web, ou seja, que permite manter o arquivo fÃsico dos dados na pasta AppData do próprio site (o que não é muito comum em provedores de hospedagem de sites aqui no Brasil).
Mas vamos ás possibilidades:
1. Em ambiente de desenvolvimento, é comum e necessário o desenvolvedor consultar os dados ou as estruturas por meio da própria IDE do Visual Studio ou do SSMS, de forma que, ao tentar executar o aplicativo posteriomente, essa conexão ainda estará aberta e, sendo neste caso uma [Ô]User Instance[Ô], torna-se então indisponÃvel ao aplicativo. Para resolver, basta sempre utilizar a opção [Ô]Close[Ô] após efetuar consultas ou exibir estruturas na IDE do Visual Studio ou no SSMS, antes de executar.
2. Se o problema ocorre em um site publicado, digo, já se encontra em um provedor, substitua o Integrated security pelas credenciais adequadas de acesso, fornecidas pelo host ou acordadas com ele, remova a cláusula User Instance e recrie o modelo Entity.
3. Se está trabalhando localmente, se observar que há duas instâncias de SQL Server em sua máquina, sendo uma o SQLEXPRESS e a outra o MSSQLSERVER, é necessário que a instância da versão EXPRESS seja a [Ô]dona[Ô] da porta 1433, padrão para a lide conjunta com o IIS. Neste caso, o menos trabalhoso e mais adequado seria manter apenas uma versão, preferencialmente a que mais se assimile áquela de mercado, no caso, a MSSQLSERVER.
4. Ainda, caso o problema que você reporta esteja de fato ocorrendo em sua máquina local ou em intranet com A.D., o problema pode ser causado por divergências entre o modelo Entity e o banco de dados atual. No entanto, não creio que seja esse o problema, pois vejo que está utilizando o aspnetdb.mdf, que é gerado automaticamente via Membership Provider.
Valew!
Repare, todavia, que a conexão requer que você esteja executando seu projeto em sua máquina local ou em uma intranet com ActiveDirectory ([Ô]Integrated Security=SSPI[Ô]) e suporte á SQL Server Express no modelo Web, ou seja, que permite manter o arquivo fÃsico dos dados na pasta AppData do próprio site (o que não é muito comum em provedores de hospedagem de sites aqui no Brasil).
Mas vamos ás possibilidades:
1. Em ambiente de desenvolvimento, é comum e necessário o desenvolvedor consultar os dados ou as estruturas por meio da própria IDE do Visual Studio ou do SSMS, de forma que, ao tentar executar o aplicativo posteriomente, essa conexão ainda estará aberta e, sendo neste caso uma [Ô]User Instance[Ô], torna-se então indisponÃvel ao aplicativo. Para resolver, basta sempre utilizar a opção [Ô]Close[Ô] após efetuar consultas ou exibir estruturas na IDE do Visual Studio ou no SSMS, antes de executar.
2. Se o problema ocorre em um site publicado, digo, já se encontra em um provedor, substitua o Integrated security pelas credenciais adequadas de acesso, fornecidas pelo host ou acordadas com ele, remova a cláusula User Instance e recrie o modelo Entity.
3. Se está trabalhando localmente, se observar que há duas instâncias de SQL Server em sua máquina, sendo uma o SQLEXPRESS e a outra o MSSQLSERVER, é necessário que a instância da versão EXPRESS seja a [Ô]dona[Ô] da porta 1433, padrão para a lide conjunta com o IIS. Neste caso, o menos trabalhoso e mais adequado seria manter apenas uma versão, preferencialmente a que mais se assimile áquela de mercado, no caso, a MSSQLSERVER.
4. Ainda, caso o problema que você reporta esteja de fato ocorrendo em sua máquina local ou em intranet com A.D., o problema pode ser causado por divergências entre o modelo Entity e o banco de dados atual. No entanto, não creio que seja esse o problema, pois vejo que está utilizando o aspnetdb.mdf, que é gerado automaticamente via Membership Provider.
Valew!
Tópico encerrado , respostas não são mais permitidas