Файл mdf заменить невозможно он используется базой данных
Я получаю следующую ошибку при отладке моего сайта visual studio 2010:
Попытка присоединить базу данных с автоматическим именем для файла C:\Users. \Desktop\Dpp2012New\App_Data\dppdatabase.mdf не удалась. База данных с тем же именем существует, или указанный файл не может быть открыт, или он находится на общем ресурсе UNC.
Описание: во время выполнения текущего веб-запроса произошло необработанное исключение. Пожалуйста, просмотрите трассировку стека для получения дополнительной информации об ошибке и о том, где она возникла в коде.
Сведения об исключении: System.Data.SqlClient.SqlException: попытка присоединить базу данных с автоматическим именем для файла C:\Users. \Desktop\Dpp2012New\App_Data\dppdatabase.mdf не удалась. База данных с тем же именем существует, или указанный файл не может быть открыт, или он находится на общем ресурсе UNC.
Вот моя строка подключения из моего web.config :
И я получаю к нему доступ с моего сайта как:
Трассировка стека показывает строку ошибки как:
Я с нетерпением жду решения.
ОТВЕТЫ
Ответ 1
Я тоже столкнулся с этой проблемой.
- Не создавайте пустую базу данных и восстанавливайте файл .bak .
- Использовать параметр "Восстановить базу данных" , нажав правой кнопкой мыши на ветке "Базы данных" в SQL Server Management Studio и указать имя базы данных в то время как обеспечивая источник для восстановления.
- Также измените имена файлов в разделе "Файлы", если другая база данных все еще существует. В противном случае вы получите "Файл". "не может быть перезаписан. Он используется базой данных" yourFirstDb ".
Ответ 2
1) Используйте WITH REPLACE при использовании команды RESTORE (если используется графический интерфейс, он находится в разделе "Параметры" → "Перезаписать существующую базу данных ( WITH REPLACE ))".
2) Delete старая база данных, которая находится в конфликте и восстанавливается снова с помощью команды RESTORE .
Проверьте ссылку для получения более подробной информации.
Ответ 3
Сначала создайте пустую базу данных с тем же именем. Затем перейдите к опции восстановления
В разделе Параметры на левой панели не забудьте выбрать
- Перезаписать существующую базу данных
- Сохранять настройки репликации
Ответ 4
У вас возникла такая же проблема и нашли решение, выполнив это, используя SSMS 2014
Ответ 5
Ответ 6
Его, потому что .mdf и .ldf файлы из оригинального Db были найти в возможно c:\programFile\. и эта информация сохраняется в резервном хранилище!
Если вы создаете одну и ту же БД на другом сервере SQL Server, где выполняется установка в c:\program Files (x86)\. вы не сможете восстановить как обычно. Вам нужно переместить путь для .mdf и .ldf файлов.
Создать пустую БД на новом Сервере
Щелкните правой кнопкой мыши на пустой базе данных Db> Задачи> Восстановление> База данных> щелкните Устройство, выберите файлы .bak > Выберите Db, чтобы восстановить в
Готово!
Надеюсь, поможет!
Ответ 7
1- Щелкните правой кнопкой мыши базу данных> Задачи> восстановить> База данных
2- Проверьте Device как источник и найдите файл .bak
3- В левой панели нажмите на options и:
- установите флажок " Перезаписать существующую базу данных".
- снимите флажок перед созданием резервной копии
- проверить закрыть Существующее соединение с базой данных назначения.
- другие варианты действительно необязательны!
Ответ 8
Сегодня я столкнулся с подобной проблемой. Пробовал все вышеупомянутые решения, но не работал. Поэтому отправьте мое решение здесь.
Не забывайте отключить резервное копирование с помощью Tail-long перед восстановлением
Надеюсь, что это тоже поможет другим!
Ответ 9
Если вы используете сценарий и у вас есть ошибка, связанная с файлами LDF и MDF, вы можете сначала запросить в файле резервной копии логические имена (и другие подробности) файлов в наборе резервных копий, используя следующее:
Вы получите результаты, подобные следующим:
И тогда вы можете использовать эти логические имена в запросах:
Дополнительную информацию о RESTORE FILELISTONLY можно найти в документации по SQL Server.
Ответ 10
Также важно убедиться, что ваше имя базы данных соответствует имя базы данных в резервной копии, которую вы пытаетесь восстановить. Если он не совпадает, вы получите ту же ошибку.
Ответ 11
Прежде чем делать что-либо еще, подтвердите, является ли ваша резервная копия полной или дифференциальной. Если вы пытаетесь создать новую базу данных из дифференциальной резервной копии, независимо от того, что вы делаете, вы столкнетесь с этой ошибкой.
Ответ 12
system.data.sqlclient.sqlerror: набор резервных копий содержит резервную копию базы данных, отличной от существующей базы данных "Dbname"
Я наткнулся, чтобы найти душевное равновесие
Не создавайте базу данных с тем же именем или другим именем! Важно.
щелкните правой кнопкой мыши базу данных | Задачи> Восстановление> База данных
В разделе "Источник для восстановления" выберите "С устройства"
Выберите файл .bak
Установите флажок для базы данных в сетке ниже
В базу данных: "Здесь вы можете ввести новое имя базы данных" (например: DemoDB)
Не выбирайте существующую базу данных из DropDownlist
Теперь нажмите кнопку Ok, она создаст новую базу данных и восстановит все данные из вашего файла .bak.
Надеюсь, это поможет разобраться в вашей проблеме.
Ответ 13
Такая же проблема со мной. Решение для меня:
- Щелкните правой кнопкой мыши по базе данных.
- Выберите задачи, выберите базу данных восстановления.
- Выберите параметры с левой стороны.
- Проверить первый вариант OverWrite существующей базы данных (WITH REPLACE).
- Перейдите в раздел Общие, выберите базу данных источника и назначения.
- Нажмите "ОК", чтобы он
Ответ 14
Я просто пытался решить эту проблему.
Я пробовал все: от запуска до администратора до предложений, найденных здесь и в другом месте; то, что в конечном итоге решило это для меня, было проверить параметр "Переместить файлы" на вкладке "Свойства файлов".
Надеюсь, это поможет кому-то еще.
Ответ 15
Мне пришлось создать новый db на моем локальном для тестирования, и у меня была резервная копия от моего продукта. Сначала я создал db и попытался запустить BAK поверх нового db, который произвел эту ошибку для меня. Я удалил db и восстановил его при поиске нового имени db на самом экране восстановления. ДБ автоматически создается при восстановлении.
Ответ 16
Я получил работу через альтернативный путь, используя Generate scripts. Это работало для меня, поскольку Backup-Restore не помог решить проблему из-за той же ошибки.
Ответ 17
Некоторые из вас очень сильно усложняют это. Я нашел это очень простым.
1) Создайте базу данных с тем же именем, что и имя вашей базы данных .bak! Важно
2) щелкните правой кнопкой мыши базу данных | Задачи > Восстановить > База данных
3) В разделе "Источник для восстановления" выберите "От устройства"
4) Выберите файл .bak
5) Установите флажок для базы данных в виде сетки ниже
6) В разделе "Выбрать страницу" справа выберите "Параметры"
7) Установите флажок "Сохранить параметры репликации (WITH KEEP_REPLICATION)
Теперь вернитесь на страницу "Общие" и нажмите "ОК", чтобы восстановить базу данных. Вот и все.
Ответ 18
В параметрах измените имя файла "Восстановить как" на новую базу данных mdf и ldf. Он ссылается на файлы базы данных .mdf и .ldf.
Ответ 19
Вы можете восстановить новый БД, проверить синтаксис имени файла, он будет в файле журнала, так как новая версия SQL будет суффиксом "_log"
ad проверить перезапись существующего флага базы данных на вкладке параметров
Ответ 20
Я уверен, что эта проблема связана с разрешениями файлов и папок.
Ответ 21
Я пытался восстановить производственную базу данных в промежуточную базу данных на том же сервере.
Единственное, что сработало в моем случае, - это восстановление новой пустой базы данных. Это отлично работало, не пыталось перезаписать производственные файлы (что было бы, если бы вы просто восстановили файл резервной копии в существующую промежуточную базу данных). Затем удалите старую базу данных и переименуйте - файлы сохранят новое имя temp, но в моем случае это нормально.
(Или иначе удалите промежуточную базу данных, а затем вы можете восстановить новую базу данных с тем же именем, что и промежуточная база данных)
Ответ 22
вместо того, чтобы щелкнуть Восстановить базу данных, нажмите Восстановить файл и файловые группы.
В основном я следил за учебником и решил удалить файл .mdf впоследствии.
Моя строка подключения следующая:
Я пробовал посмотреть на Обозреватель объектов SQL Server, но он выглядит следующим образом:
Кроме того, в Server Explorer я не вижу никаких соединений с данными.
И когда я пытаюсь добавить новое соединение в Server Explorer, я не вижу никаких баз данных с именем OdeToFoodDb .
Извините за этот широкий вопрос, но я новичок в Entity Framework и не совсем понимаю, что здесь не так.
ОТВЕТЫ
Ответ 1
У меня тоже была эта проблема, и это было больно. Я настроил строку подключения и смог решить проблему. В строке подключения я заменил значение | DataDirectory |\dbfilename.mdf для свойства AttachDbFilename с указанием пути к файлу. | DataDirectory | может использоваться только в том случае, если файл базы данных находится в папке App_Data внутри того же проекта.
Таким образом, изменив свойство AttachDbFilename на прямой путь к файлу mdf, я исправил свою проблему.
AttachDbFilename = C:\MyApp\App\ДАЛ\db.mdf
Я надеюсь, что это сработает для вас.
Ответ 2
Попробуйте создать строку подключения, как показано ниже:
Это работает для меня.
Ответ 3
У меня была аналогичная ошибка, но с использованием соединения, настроенного в коде, а не файла конфигурации. Решение для меня было просто добавить часть "Начальный каталог = MyDatabase". Теперь мой код выглядит как.
Местоположение - это полный путь к файлу mdb, который еще не существует.
Ответ 4
Ответ 5
Одна из самых неприятных ошибок при разработке веб-приложений в .NET. У меня была эта проблема в проекте, который я делал год назад. Это то, что сработало для меня: я вошел в систему с учетной записью sa в SQL Management Studio и привязал базу данных к проводнику объектов (Базы данных → Щелкните правой кнопкой мыши → Прикрепить). Затем я открыл Security- > Logins → [myWindowsUsername] и отредактировал вкладку "Сопоставления пользователей", предоставив права dbowner на присоединенную базу данных.
Я уверен, что вы можете делать эти вещи без Management Studio с консольными командами, но я не так хорош с T-SQL и не могу дать вам совета по этому поводу.
Ответ 6
проверьте свой файл веб-конфигурации, может быть несколько строк соединения с таким же именем
Ответ 7
Mine был первым проектом EF-кода, и он появляется, когда файл был удален. Запуск Update-Database из консоли диспетчера пакетов делает базу данных и ее штраф.
Ответ 8
Ошибка была исправлена для меня после того, как я изменил этот
Ответ 9
Я установил папку установки из файлов программы в каталог C, пока я устанавливаю приложение. то моя проблема решена.
Ответ 10
Я думаю, причина в том, что в вашем каталоге базы данных содержится файл .mdf с таким же именем. Лучше всего дать полный путь, который вы можете просто заменить AttachDbFilename. просто получите полный путь к файлу базы данных и назначьте его в AttachDbFilename, которое находится в файле app.config.
Ответ 11
В большинстве случаев проект unit test отделен от основного проекта. Это приводит к тому, что сгенерированная строка соединения является недопустимой, поскольку она не может найти папку app_data, если ваш db является локальным для решения.
Вы можете просто заменить DataDirectory | с относительным путем к вашему db в вашем основном проекте, если вам нужно подключиться к нему из вашего проекта unit test.
Ответ 12
Ответ 13
Я пытаюсь переносить mdf в моем приложении, поэтому я использовал
с nerdDinners, я не могу вспомнить, где я его нашел, будучи
Затем я могу использовать возвращаемый тип как DbContext.
Основное, с чем я столкнулся, это то, что GetCurrentDirectory() получает скомпилированный путь к файлу, а не путь к файлу проекта, поэтому для развертывания должен быть установлен GetCurrentDirectory, а mdf следует скопировать при компиляции, а не ссылаться на фактические App_Data. Включите ваш mdf в свой проект и перейдите на него. Установите копию в выходной каталог.
Ответ 14
У меня была такая же проблема с EF. Решение абсолютного пути сработало. Но это не очень хорошее решение, если вы хотите переместить вашу программу в новое место. Для меня это было проблемой.
- VS ищет файл mdf в папке отладки
- В папке проекта .mdf файл .mdf , иногда VS синхронизирует два файла
- По какой-то причине .mdf файл не был синхронизирован в Debug
Мой обходной путь:
Ответ 15
то, что я нашел до сих пор, чтобы решить проблему, если вы создадите mdf файл описанным ниже способом, он отлично подойдет для visual studio.
Щелкните правой кнопкой мыши соединение для передачи данных на сервере Explorar-> добавьте connection-> выберите файл базы данных Microsoft SQL Server, выберите имя базы данных и выберите okay. Тогда эта проблема не возникает. Следуйте за видео: ссылка на YouTube
Ответ 16
Похоже, для этого есть много причин. Здесь была моя.
System.Data.SqlClient.SqlException: 'Попытка присоединить базу данных с автоматическим именем для файла Q:\Folder\FileName.mdf не удалась. База данных с тем же именем существует, или указанный файл не может быть открыт, или он находится на общем ресурсе UNC. '
В попытке воспроизвести производственную среду. У меня изначально был физический диск Q :. После того, как моя машинка зашла в тупик.. Я перестроил и просто создал подключенный диск. Начал получать эту ошибку. а затем вернулся и просто создал еще один раздел Q: и проблема была решена.
Ответ 17
У меня была похожая проблема после того, как я переместил свою базу данных в папку в том же проекте.
Наконец, все, что мне нужно было сделать, - это просмотреть свойства базы данных, скопировать путь, указанный в разделе "identity", и заменить его на "AttachDbFilename post-104 post type-post status-publish format-standard has-post-thumbnail hentry category-uncategorized">
Ответ 18
Попробуйте это, у меня это работает
Ответ 19
У меня была та же проблема, и я думаю, что понял это. В строке подключения убедитесь, что строка подключения выглядит так:
- это то, что появляется по умолчанию в файле web.config. Оставьте его неизменным и добавьте еще одну строку подключения
Есть 1С-сервер, есть MySQl-сервере
Работают в связке. 10 баз.
1 база перестала загружаться ни в 1С предприятие, ни в конфигуратор. Проходит аутентификация, затем зависает и отключается по таймауту. Проверка SQl-базы на ошибки ничего не дало, ошибок нет.
Зависание с 1 базой происходит под любым пользователем и даже если сделав бекап поставить её на другую базу, происходит тоже.
Подскажите, как решить данную проблему.
Зараннее, спасибо.
службы сервера 1с предприятия, может не достаточно будет для перегрузки, желательно перегрузить сервер, если это возможно.
1.) ребут сервера 1С и SQL
2.) скопировать базы с SQL или снять бекап, и поднять заново в новой SQl базе, если есть другой сервак на нем, после этого подрубить как новую базу к серверу 1С Предприятия
3.) взять самый свежий архив и плакать, у нормального админа должен делаться каждую ночь
4.) искать умельцев, в прошлой конторе нашли какого умельца, который восстановил поврежденные SQL таблицы
Итак, приступим. Ситуация следующая: имеется сервер с запущенной на нем 1С+SQL. Во время работы SQL базы рубанули питание. Результат плачевный: база находится в состоянии suspect, и когда 1с пытается к ней зацепиться, выдается ошибка, что мол соединиться невозможно т.к. база помечена suspect for recovery. Этот режим в принципе означает, что MSSQL Server попытается восстановить базу своими средствами. Я не стал ни чего трогать и оставил все на ночь, в надежде, что к утру база восстановится, но и утром было то же самое, и к базе, стало быть, ни как не подобраться. Backup по закону подлости имеется, но он трехдневной давности, плюс имеется куча документов которые проводятся лишь по базе, а по бумажным документам их нет, т.е. возможности вручную восстановить документы нет. Потратив кучу сил, и нервов, (которые, как известно не восстанавливаются :)), я пришел к следующей последовательности действий, необходимых для восстановления базы.
1) Основной принцип поначалу – не навреди. Глушим SQL server и копируем *.mdf и *.ldf файлы от базы в сторону.
2) В принципе, бывает, что состояние suspect возникает из-за того, что поменялись пути к файлам с базой (например, добавился новый диск в системе, который потом убрали, переименовали папку с базой и т.д.). Затем, конечно же, пути восстановили, но база все равно остается помеченной как suspect. Вот что мы делаем:
3) Запускаем SQL Server.
4) Пробуем подключить базу через Enterprise Manager:
Правой кнопкой по Databases, в появившемся меню выбираем All tasks->Attach database, затем в появившемся диалогов окне выбираем файл с базой (*.mdf) и устанавливаем необходимые параметры.
5) или через Query Analyser примерно такой командой:
a. sp_attach_db @dbname = 'DemoXMB',
b. @filename1 = 'E:\Data\DemoXMB_Data.MDF',
c. @filename2 = 'E:\Data\DemoXMB_Log.LDF'
6) Пути к базе, естественно нужно заменить на свои. Если база подключилась, то, можно сказать, отделались легким испугом, если же нет, то продолжим.
7) Если log-файл не поврежден (*.ldf), а поврежден *.mdf (например, при подключении базы sql ругается на ошибки в mdf-файле), и режим сохранения backup'а стоит full, то восстанавливаем базу без восстановления лога транзакций, почти 100%, что все мучения на этом могут закончиться.
8) Если же наоборот, поврежден ldf-файл, но остался *.mdf файл, при подключении база ругается на отсутствие/повреждение лога транзакций. В этом случае можно воспользоваться ХП "sp_attach_single_file_db"
Например:
use master
EXEC sp_attach_single_file_db @dbname = 'DemoXMB',
@physname = 'c:\mssql7\data\DemoXMB_Dat.mdf'
При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением.
Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП "sp_attach_db"
Например:
use master
EXEC sp_attach_db @dbname = 'DemoXMB',
@filename1 = 'c:\mssql7\data\DemoXMB_Dat.mdf',
@filename1 = 'c:\mssql7\data\DemoXMB_Log.ldf'
Для подключения более 16-ти физических файлов к БД следует использовать команду:
CREATE DATABASE FOR ATTACH
Однако если ничего не помогло, оказались поврежденными оба файла и база всё еще в состоянии suspect, то можно попробовать сбросить состояние базы следующей последовательностью: (перед использованием этой ХП необходимо разрешить прямое изменение системных таблиц)
use master
go
Разрешаем прямое изменение системных таблиц:
sp_configure 'allow updates',1
go
reconfigure with override
go
Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
sp_resetstatus 'DataBaseName'
go
А теперь запретим прямое изменение системных таблиц:
sp_configure 'allow updates',0
go
reconfigure with override
go
В принципе, когда я выполнил все эти шаги, статус suspect сбросился, НО! при попытке выполнить какие-либо действия SQL начинала ругаться, что база все еще в состоянии suspect. И тогда я сделал так:
Из QA выполняем скрипт:
Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
Там же выполняем :
update sysdatabases set status= 32768 where name = ''
Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).
Из QA выполняем:
USE ''
GO
sp_dboption '', 'single_user', 'true'
go
DBCC CHECKDB('', REPAIR_ALLOW_DATA_LOSS)
go
Если все в порядке, то:
sp_dboption '', 'single_user', 'false'
go
Use master
go
sp_configure 'allow updates', 0
go
После этого стало возможно просмотреть таблицы базы из SQL, а вот работать с ней было невозможно. Теперь необходимо при помощи Data Transformation Services экспортировать данные в новую базу. После этого проводим восстановление/тестирование базы средствами 1С. Внимание! Многие не обращают внимания на этот очень важный пункт. В результате, вы можете в один прекрасный момент обнаружить, что база восстановлена, мягко говоря, не совсем корректно. Т.е. в документе вместо номенклатуры будет стоять нечто вроде 10122/, это та проблема, которая возникла у меня, вариантов же может быть уйма. Поэтому лучше потерять время, но проверить базу средствами 1С.
Но! Здесь следует сделать паузу. Статья не была бы полной, если бы я не описал методы для предотвращения подобных проблем. Итак, самый простой и надежный способ: архивация, архивация и еще раз архивация. В Enterprise Manager заходим в меню Tools->Wizards->Management->Backup Wizard и настраиваем все необходимые параметры. В результате, у меня полный сброс SQL базы на диск происходит ночью, а затем каждые 15 минут backup изменений, внесенных в базу. В принципе, если бы у меня был такой backup, я бы за пару минут сделал откат назад, и продолжил бы попивать Coca-Cola :).
Где должны находиться файлы базы данных sql *mdf и *.ldf?
У меня они находятся в каталоге базы, *mdf -3Гб, *ldf - 2 Гб. Хорошо ли так делать? Может ли из-за этого быть замедление работы? Это сделали до меня.
И еще вопрос. Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы. Про индексацию базы после сбоев предупредила. Чего еще ожидать? Что делать с sql файлами в каталоге базы?
"Земную жизнь пройдя до половины. " как сказал поэт.
Тут уже немного за половину: после 1 гигабайта начнутся проблемы по чтению, придется лепить приблуду kernel33.dll
Что касается SQL-баз - "умные люди" советуют держать лог-файл журнала (*.ldf) на отдельном диске, сам файл базы на другом - это также и 7-чных баз данных касается. Что касается расположения файлов - лучше располагать поближе к "корню диска" и не использовать кириллических символов в названии папок.
Где должны находиться файлы базы данных sql *mdf и *.ldf? - согласна с ответом 4.
Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы
Это что за функции такие, может их не так много и имеет смысл адаптировать под SQL
(5) Я даже не хочу об этом думать. Там почти самописная конфигурация, очень сложная и запутанная в смысле количества документов и процессов.
Базу будем резать однозначно, но вот хотят попробовать перейти на скл, что может под ним будет комфортнее работать.
Может ли дать заметный эффект в скорости если просто скл файлы перенести в другое место, как написано в (4)?
М-да. Вы для начала хоть с направлением определитесь однозначно, а то собираетесь переходить одновременно в противоположных направлениях.
(7)Сорри, это описка. На дбф хотят перейти.
На тестовом сервере в дбф версии многие отчеты работают быстрее. И загрузка самой базы в разы быстрее. Да и вообще тестовый сервер работает быстрее. Может потому что на нем никто не работает, а может, потому что у меня файлы скл сервера лежат не в каталоге базы. ?
Нет. Без модернизации конфигурации заметного прироста не будет.
Действительно, при использовании 1cv77 и MS SQL есть ряд проблем с выполнением регламентных операций
однако при больших объемах данных SQL дает значительный прирост производительности в обычной работе пользователей (операции чтения/записи).
Тут надо рассматривать ситуацию исходя их количества одновременных операций ввода данных. Объема отчетных данных.
Анализа используемых алгоритмов и оптимизации.
Проблемы с выполнением регламентных операция можно обойти следующим образом:
1. Выгрузка в ДБФ
2. Выполнение регламентных операций в монопольном режиме (перепроведение и т.д.)
3. Загрузка в SQL
Особенной разницы в расположении конфигурационных файлов нет. Объем данных конфигурации (md) небольшой.
По поводу файлов.
По "феншую" mdf и ldf на разных физических дисках. НО если файлы лежат на том же компьютере где установлен SQL никакой разницы вы не заметите.
По хорошему - методами ускорения будет:
- Перевод на прямые запросы
- Использование УРИБ для разделения ввода данных
Я пытаюсь восстановить файл резервной копии SQL Server для своей базы данных, но он вызывает ошибку, как показано ниже:
Набор резервных копий содержит резервную копию базы данных, отличной от существующей
Моя база данных в SQL Server 2008 и файл резервной копии находятся в 2005 году.
В чем может быть проблема?
ОТВЕТЫ
Ответ 1
Edit Этот ответ был принят, поскольку он подтверждает ошибку и обходной путь, используемый OP (переименование базы данных может помочь). Я полностью согласен с тем, что переименование базы данных на самом деле не является приемлемым способом, а не полностью решает проблему. К сожалению, я не проверял другие способы решения этой проблемы в SSMS.
Ответ 2
Я думаю, что для SQL Server Local Db вы не должны использовать свойство Initial Catalog . Я предлагаю использовать:
Я думаю, что локальный db не поддерживает несколько баз данных в одном файле mdf, поэтому указать, что начальный каталог не поддерживается (или не поддерживается хорошо, и у меня есть некоторые странные ошибки).
Ответ 3
Запустите консоль диспетчера пакетов:
sqllocaldb.exe stop v11.0
sqllocaldb.exe delete v11.0
Ответ 4
Удалите эту строку из строки подключения, которая должна это сделать;) "AttachDbFilename = | DataDirectory | whateverurdatabasenameis-xxxxxxxxxx.mdf"
Ответ 5
Я столкнулся с той же проблемой. Следующие шаги в VS 2013 решили для меня проблему:
- В проводнике сервера добавьте новое подключение к базе данных
- Выберите файл базы данных Microsoft SQL Server в качестве источника данных
- Выберите имя файла базы данных, так как оно должно быть в соответствии со строкой подключения в вашем веб файле
- Был создан новый файл базы данных, и в Server Explorer появилось два подключения к базе данных: "MyDatabaseName" и "MyDatabaseName (MyProjectName)"
- Удалить одно соединение (я удалил "MyDatabaseName" )
Ответ 6
"Не удается подключить файл 'C:\Github\TestService\TestService\App_data\TestService.mdf" в качестве базы данных' TestService '
Ответ 7
В соответствии с @davide-icardi удалите "Initial Catalog = xxx;" от web.config, но также проверьте, чтобы ваш файл профиля azure публиковал его и здесь:
[Путь YourAspNetProject]\Свойства\PublishProfiles [YourAspNetProjectName].pubxml
Ответ 8
Я обнаружил, что комментирование контекстного раздела, используемого для инициализации базы данных, разрешило проблему. Havnt успел выяснить, что было не так с заявлениями о посеве, но удаление посевного материала разрешило проблему.
Ответ 9
У вас уже есть старая копия этой базы данных, установленная в Server Explorer. Таким образом, это простое столкновение имен в Server Explorer/SQL Server. Вероятно, вы создали ту же самую базу данных, что и имя Каталога, прежде чем решили перенести ее в папку Apps_Data. Так что имя базы данных уже существует и просто нужно удалить.
Просто зайдите в Visual Studio > View > SQL Server Object Explorer и удалите старое имя базы данных и ее соединение. Повторите попытку снова, и он должен установить файл .mdf в App_Data и снова создать ту же самую точную базу данных в Server Explorer.
Ответ 10
У меня была такая же ошибка, следуя учебному руководству "Начало работы с ASP.NET MVC 5 | Microsoft Docs". Я был на Visual Studio 2015. Я открыл View- > SQL Server Object Explorer и удалил базу данных, названную после учебника, и тогда она может работать. см. Удалить файл .mdf из app_data вызывает исключение не может прикреплять файл как базу данных
Ответ 11
Создайте новую базу данных. Не удаляйте его, и ваше приложение должно продолжать работать.
Ответ 12
Совершенно работающий проект (почти) всегда создает базу данных (включая файлы) автоматически. Это может быть любая команда, чтение, запись, обновление. Файлы создаются. Конечно, он использует
Есть только один случай, когда он беспокоится: если mdf автоматически создается, и вы удаляете файл mdf и log. Тогда это было об этом. Попрощайтесь с вашим автообновлением.
После этого все возвращается в нормальное состояние (и все остальные базы данных, обработанные LocalDB, также ушли!).
EDIT: Это было неверно. Я просто попробовал, и v11.0 автоматически воссоздается, и все mdfs остаются доступными. Я не пробовал "LocalDBs с нефайловыми базами".
Сбивая с толку, я также получил эту ошибку, если что-то еще не так. Поэтому я хочу сказать, что если вы хотите, чтобы ваш DB-Setup был прочным и прочным: Создайте новое решение/проект с нуля, используйте самые базовые команды БД (добавьте сущность, покажите все сущности, удалите все сущности) и посмотрите, работает ли она.
Если ДА, проблема находится где-то в пучине конфигурации VS2013 и версиях, а также nuget и т.д.
ЕСЛИ НЕТ, у вас возникла проблема с установкой LocalDB.
P.S.: Поднимите меня, если вам нужен проект проекта.
Ответ 13
Причина: происходит потому, что вы удалили файлы поддержки .mdf, ldf без фактического удаления базы данных в запущенном экземпляре SqlLocalDb; повторное выполнение кода в VS не поможет, потому что вы не можете повторно создать БД с тем же именем (и поэтому переименование работает, но оставляет старое имя phantom db).
Исправление: Я использую VS2012, аналогично использую для другой версии.
Перейдите к следующему пути и введите
c:\program files\microsoft sql server\110\Tools\Binn > sqllocaldb info
Над cmd показаны имена экземпляров, включая 'v11.0'
Если экземпляр уже запущен, введите в командной строке
Если состояние не запущено или остановлено, запустите экземпляр с помощью
и извлеките ту же информацию, что и выше.
В диалоговом окне "Подключение" панели управления SS введите
После подключения найдите phantom DB, который вы удалили (например, YourDB.mdf должен был создать db с именем YourDB) и действительно удалить его.
Готово! Как только это уйдет, VS EF не будет иметь проблем с повторным созданием.
Ответ 14
Как ни странно, для той же самой проблемы, что помогло мне, было изменение "to" v11.0 "в следующем разделе конфигурации.
Ответ 15
Недавно я столкнулся с той же проблемой. Вот одно, что нужно проверить. в визуальной студии есть три места, которые мы должны проверить и удалить базу данных.
Когда я удаляю базу данных из первых двух точек, ошибка все равно возникает. Итак, мне нужно было удалить базу данных из Обозревателя объектов SQL Server. Тогда я мог бы легко запустить команду "update-database" без ошибок. Надеюсь это поможет.
Читайте также: