Помилка 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" />

Тому що я завжди отримую помилку:

Основний провайдер не вдався на Open

У мене виникла помилка, і я знайшов кілька рішень:

Дивлячись на ваш рядок з'єднання, це виглядає дійсно. Я знайшов цю публікацію в блозі , проблема тут у тому, що вони використовували інтегровану безпеку . Якщо ви працюєте на 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, Компонентські послуги -> Комп'ютери -> Мій комп'ютер -> Координатор розподілених транзакцій -> Клацніть правою кнопкою миші Локальний DTC -> Захист.

Ви повинні побачити InternalException, щоб побачити, яка внутрішня причина помилки.

У моєму випадку первісна помилка була:

Неможливо відкрити фізичний файл "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 з тією ж конфігурацією я отримав цю помилку:

Основний провайдер не вдався на Open

Це було вирішено, змінивши 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. Ім'я користувача та пароль можуть бути помилковими.

Отримавши цей виняток, переконайтеся, що розгорніть деталі та ознайомтеся з внутрішніми деталями виключення, оскільки вони містять детальну інформацію про те, чому не вдалося ввійти. У моєму випадку рядок з'єднання містив користувача, який не мав доступу до моєї бази даних.

Незалежно від того, чи використовуєте Ви інтегровану безпеку (контекст, на який увійшли користувач 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

Я розмістив подібну проблему тут, працюючи з db SQL 2012, розміщеним на Amazon RDS. Проблема була в рядку підключення - у мене були властивості "Ім'я програми" та "App" . Як тільки я їх видалив, це спрацювало.

Entity Framework 5 та RDS Amazon - "базовий провайдер не вдався до Open".

Переконайтесь, що значення кожного елемента в рядку з'єднання, що постачається, є правильним. У моєму випадку я отримував ту саму помилку, оскільки ім'я каталогу (ім'я бази даних), вказане в рядку з'єднання, було невірним.

У мене була схожа проблема з винятками через стан підключення, тоді я зрозумів, що мінливий мій клас обслуговування служб домену позначений як статичний (помилково).

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

Я також думаю, що кожен виклик клієнта привів до нового потоку, тому декілька потоків, що зверталися до одного і того ж екземпляра служби домену, прирівнювались до аварії поїзда.

У мене була така ж проблема, але те, що для мене працювало, було видалення цього з рядка підключення:

persist security info=True

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

Операція не дійсна для стану угоди

Я можу це вирішити, включивши параметри безпеки DTC.

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

• Доступ до мережі DTC
• Дозволити віддалені клієнти
• Комунікація менеджера транзакцій
• Дозволити вхідне
• Дозволити вихідний

Якщо ви отримаєте цю помилку у веб-додатку ASP.NET, крім інших згаданих речей, перевірте наступне:

1. Дозволи на користування базою даних (яким користувачам надається доступ до вашої бази даних.
2. Перевірте пул додатків у IIS і переконайтеся, що це правильний доступ до вашої бази даних.

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

Визначення нового правила брандмауера Windows для сервера SQL (і для порту 1433) на серверній машині вирішує цю помилку (якщо ваше ім'я сервера, ім’я для входу або пароль користувача неправильно в рядку підключення ...).

Поширена помилка, яку я зробив, тому що я переміщував додаток з одного ПК на інший, і нічого з вищезгаданого не працювало, це те, що я забув скопіювати рядок підключення до App.Config і Web.Config!

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

Я скопіював файли бази даних (.mdf / .ldf) у папку App_Data, щоб позбутися цього винятку.

Я також стикався з тим же питанням. Тепер я це зробив, видаливши ім'я користувача та пароль із рядка з'єднання.

Для мене це була просто проста помилка:

Я використовував Amazon EC2 , і я використовував свою еластичну IP-адресу в рядку з'єднання, але коли я змінив IP-адреси, я забув оновити рядок з'єднання.

У мене ця помилка несподівано трапилася на одному з наших сайтів. У моєму випадку виявилося, що термін дії пароля користувача SQL закінчився! Скасувавши поле для закінчення терміну дії пароля в SQL Server Management Studio зробив свою справу!

У мене був такий самий випуск кілька днів тому, використовуючи "Комплексна безпека = Істинно;" у рядку з'єднання вам потрібно запустити ідентифікацію пулу додатків у "localalsystem". Звичайно, це не рекомендується, але для тестування він виконує цю роботу.

Ось як можна змінити ідентичність у IIS 7: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

У IIS встановіть ідентифікатор пулу додатків як облікового запису користувача або облікового запису адміністратора або облікового запису мураха, який має дозвіл на виконання операцій на цій базі даних.

У моєму випадку у мене було невідповідність між іменем рядка з'єднання, який я реєстрував у конструкторі контексту, і назвою в моєму web.config. Проста помилка, викликана копією та вставкою: D

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

У мене є та ж помилка, що я виявив, що коли я змінюю моє з'єднанняString на нове джерело даних, я забуваю змінити ім'я користувача та passowrd для нової бази даних

У мене також була така помилка, якщо ім'я екземпляра 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:

• Знайдіть пул додатків, клацнувши на своєму веб-сайті та перейдіть до основних налаштувань.

• Перейдіть до пулів додатків.

• Натисніть на пул додатків вашого сайту.

• Клацніть на Розширені налаштування.

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

• Перезавантажте веб-сайт і повторіть спробу.