Ошибка MSSQL «Основной поставщик не удалось открыть»

Я использовал .mdfдля подключения к databaseи entityClient. Теперь я хочу изменить строку подключения, чтобы не было .mdfфайла.

Правильно ли следующее connectionString?

<connectionStrings>
   <!--<add name="conString" connectionString="metadata=res://*/conString.csdl|res://*/conString.ssdl|res://*/conString.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQL2008;AttachDbFilename=|DataDirectory|\NData.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />-->
   <add name="conString" connectionString="metadata=res://*/conString.csdl|res://*/conString.ssdl|res://*/conString.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQL2008;Initial Catalog=NData;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />

Потому что я всегда получаю ошибку:

Основной поставщик не удалось открыть

У меня была эта ошибка и я нашел несколько решений:

Глядя на строку подключения, она выглядит действительной. Я нашел это сообщение в блоге , проблема здесь в том, что они использовали встроенную безопасность . Если вы работаете в IIS, вашему пользователю IIS необходим доступ к базе данных.

Если вы используете Entity Framework с транзакциями , Entity Framework автоматически открывает и закрывает соединение с каждым вызовом базы данных. Поэтому при использовании транзакций вы пытаетесь распределить транзакцию по нескольким соединениям. Это повышается до MSDTC .

( См. Эту ссылку для получения дополнительной информации. )

Изменение моего кода на следующее исправило это:

using (DatabaseEntities context = new DatabaseEntities())
{
    context.Connection.Open();
    // the rest
}

context.Connection.Open() не помогло решить мою проблему, поэтому я попытался включить «Разрешить удаленных клиентов» в конфигурации DTC, больше никаких ошибок.

В windows 7 вы можете открыть конфигурацию DTC, выполнив команду dcomcnfg, Службы компонентов -> Компьютеры -> Мой компьютер -> Координатор распределенных транзакций -> Щелкните правой кнопкой мыши локальный код неисправности -> Безопасность.

Вы должны увидеть innerException, чтобы увидеть, какова внутренняя причина возникновения ошибки.

В моем случае исходная ошибка была:

Невозможно открыть физический файл "D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData_log.ldf". Ошибка операционной системы 5: «5 (доступ запрещен.)». Попытка присоединить базу данных с автоматическим именем для файла D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData.mdf не удалась. База данных с тем же именем существует, или указанный файл не может быть открыт, или он находится на общем ресурсе UNC.

что решается путем предоставления полного разрешения текущему пользователю для доступа к связанным mdfи ldfфайлам, используя свойства файлов.

Я обнаружил, что проблема заключалась в том, что у меня был путь к серверу в строке подключения в одном из следующих вариантов:

SERVER\SQLEXPRESS
SERVER

Когда на самом деле я должен иметь:

.\SQLEXPRESS

По какой-то причине я получаю сообщение об ошибке всякий раз, когда возникают трудности с поиском экземпляра SQL.

Это общая проблема только. Даже я сталкивался с этой проблемой. На компьютере разработчика, настроенном с аутентификацией Windows, он работает отлично:

<add name="ShoppingCartAdminEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=.\SQlExpress;initial catalog=ShoppingCartAdmin;Integrated Security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

После размещения в IIS с той же конфигурацией я получил эту ошибку:

Основной поставщик не удалось открыть

Было решено изменение connectionStringв файле конфигурации:

<add name="MyEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=MACHINE_Name\SQlExpress;initial catalog=ShoppingCartAdmin;persist security info=True;user id=sa;password=notmyrealpassword;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Другие распространенные ошибки могут быть:

1. Служба базы данных может быть остановлена
2. Атрибуты источника данных, указывающие на локальную базу данных с аутентификацией Windows и размещенные в IIS
3. Имя пользователя и пароль могут быть неверными.

Когда вы получите это исключение, убедитесь, что вы расширили детали и посмотрите на внутренние детали исключения, так как они предоставят подробные сведения о том, почему не удалось войти в систему. В моем случае строка подключения содержала пользователя, который не имел доступа к моей базе данных.

Независимо от того, используете ли вы Integrated Security (контекст зарегистрированного пользователя Windows) или отдельную учетную запись SQL, убедитесь, что у пользователя есть надлежащий доступ в разделе «Безопасность» к базе данных, к которой вы пытаетесь получить доступ, чтобы предотвратить эту проблему.

У меня была похожая проблема с SQL Server Express Edition на Windows Server 2003 . Я просто добавил сетевой сервис как пользователь в базу данных безопасности.

Служба SQL Server Express не была запущена автоматически.

1) Перейти на панель управления 2) Администрирование 3) Сервис 4) Установить автоматический запуск SQL Server, нажав на него 5) Щелкните правой кнопкой мыши и запустите службу

Я надеюсь, что это поможет.

Это также может произойти, если вы восстанавливаете базу данных, и пользователь уже существует с другой схемой, и вы не можете назначить правильные разрешения.

Чтобы исправить этот прогон:

USE your_database
EXEC sp_change_users_login 'Auto_Fix', 'user', NULL, 'cf'
GO
EXEC sp_change_users_login 'update_one', 'user', 'user'
GO

Я опубликовал похожую проблему здесь, работая с базой данных SQL 2012, размещенной на Amazon RDS. Проблема была в строке подключения - там были свойства «Имя приложения» и «Приложение» . Как только я удалил их, все заработало.

Entity Framework 5 и Amazon RDS - «Основной поставщик не удалось открыть».

Убедитесь, что каждое значение элемента в строке подключения указано правильно. В моем случае я получал ту же ошибку, потому что имя каталога (имя базы данных), указанное в строке подключения, было неверным.

У меня была похожая проблема с исключениями из-за состояния соединения, затем я понял, что моя переменная класса обслуживания домена помечена как статическая (по ошибке).

Я предполагаю, что, как только сервисная библиотека загружается в память, каждый новый вызов заканчивается использованием одного и того же значения статической переменной (экземпляр службы домена), что вызывает конфликты через состояние соединения.

Я также думаю, что каждый клиентский вызов приводил к созданию нового потока, поэтому несколько потоков, обращающихся к одному и тому же экземпляру службы домена, приравнивались к железнодорожной аварии.

У меня была та же проблема, но что работало для меня, так это удаление этой строки подключения:

persist security info=True

У меня была похожая ошибка с внутренним исключением, как показано ниже:

операция недействительна для состояния транзакции

Я мог бы решить это, включив настройки безопасности DTC.

Перейти к свойствам DTC, под вкладкой Безопасность, проверьте ниже

• Доступ по сети DTC
• Разрешить RemoteClients
• Менеджер транзакций
• Разрешить входящий
• Разрешить исходящий

Если вы столкнулись с этой ошибкой в ​​веб-приложении ASP.NET, помимо прочего, отметьте следующее:

1. Разрешения безопасности пользователя базы данных (каким пользователям разрешен доступ к вашей базе данных.
2. Проверьте пул приложений в IIS и убедитесь, что это правильный доступ к вашей базе данных.

Я избавился от этого, сбросив IIS , но все еще используя Integrated Authenticationв строке подключения.

Определение нового правила брандмауэра Windows для SQL Server (и для порта 1433) на компьютере сервера решает эту ошибку (если ваше имя сервера, имя пользователя или пароль не указаны в строке подключения ...).

Распространенная ошибка, которую я совершил, потому что я переносил приложение с одного компьютера на другой, и ничего из вышеперечисленного не работало, заключался в том, что я забыл скопировать строку подключения в App.Config и Web.Config!

У меня была похожая проблема: в моих тестовых примерах я всегда получал эту ошибку. Я обнаружил, что моя «Служба распределенных транзакций» не была запущена (запустите: services.msc -> start «Служба распределенных транзакций» (лучше всего настроить ее на автоматический запуск)). После того, как я это сделал, это сработало как шарм ...

Я скопировал файлы базы данных (.mdf / .ldf) в папку App_Data, чтобы избавиться от этого исключения.

Я также столкнулся с той же проблемой. Теперь я сделал это, удалив имя пользователя и пароль из строки подключения.

Для меня это была просто простая ошибка:

Я использовал Amazon EC2 и использовал свой эластичный IP-адрес в строке подключения, но когда я изменил IP-адреса, я забыл обновить строку подключения.

У меня была такая ошибка, неожиданно возникшая на ровном месте на одном из наших сайтов. В моем случае оказалось, что срок действия пароля пользователя SQL истек! Сняв флажок истечения срока действия пароля в SQL Server Management Studio, добились цели !

У меня была такая же проблема несколько дней назад, с использованием "Integrated Security = True;" в строке подключения вам нужно запустить удостоверение пула приложений в «localsystem». Конечно, это не рекомендуется, но для тестирования это делает свою работу.

Вот как вы можете изменить удостоверение в IIS 7: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

В IIS установите для идентификатора пула приложений учетную запись пользователя службы, учетную запись администратора или учетную запись ant, у которой есть разрешение на выполнение операций с этой базой данных.

В моем случае у меня было несоответствие между именем строки подключения, которое я регистрировал в конструкторе контекста, и именем в моем web.config. Простая ошибка, вызванная копированием и вставкой: D

    public DataContext()
        : base(nameOrConnectionString: "ConnStringName")
    {
        Database.SetInitializer<DataContext>(null);
    }

у меня та же ошибка, что я обнаружил, что, когда я изменяю свой connectionString на новый источник данных, я забываю изменить имя пользователя и пароль для новой базы данных

У меня также была эта ошибка, если имя экземпляра SQL Server не указано и на хосте SQL установлено несколько экземпляров SQL. Вот пара примеров для пояснения:

Приведенная ниже строка подключения приводит к исключению «Основной поставщик не удалось открыть» без внутреннего исключения в приложении .NET WebForms:

 connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"

Следующая строка подключения выполняется, как и ожидалось, в приложении .net WebForms, где среда SQL имеет несколько экземпляров. Редко я знаю, но у меня есть несколько разных экземпляров SQL на моем компьютере разработчика для разных проектов:

 connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost\SQLSERVER2014;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"

в моем случае адрес сервера был изменен администратором сервера, поэтому мне пришлось изменить строку подключения на новый адрес сервера

У меня была эта проблема, потому что имя входа в пул приложений, под которым работало это приложение, изменилось.

В IIS:

• Найдите пул приложений, нажав на свой сайт и перейдя в раздел «Основные настройки».

• Перейдите в пулы приложений.

• Нажмите на пул приложений вашего сайта.

• Нажмите на Дополнительные настройки.

• В удостоверении введите логин и пароль учетной записи.

• Перезапустите свой сайт и попробуйте снова.