Mdf не является действительным заголовком файла базы данных свойство pageaudit неверно

Обновлено: 05.07.2024

Каждая база данных SQL Server имеет как минимум два рабочих системных файла: файл данных и файл журнала. Файлы данных содержат данные и объекты, такие как таблицы, индексы, хранимые процедуры и представления. Файлы журнала содержат сведения, необходимые для восстановления всех транзакций в базе данных. Файлы данных могут быть объединены в файловые группы для удобства распределения и администрирования.

Файлы базы данных

SQL Server имеют три типа файлов.

Файл	Описание
Первичная	Содержит сведения, необходимые для запуска базы данных, и ссылки на другие файлы в базе данных. В каждой базе данных имеется один первичный файл данных. Для имени первичного файла данных рекомендуется расширение MDF.
Вторичная	Необязательные определяемые пользователем файлы данных. Данные могут быть распределены на несколько дисков, в этом случае каждый файл записывается на отдельный диск. Для имени вторичного файла данных рекомендуется расширение NDF.
Журнал транзакций	Журнал содержит информацию для восстановления базы данных. Для каждой базы данных должен существовать хотя бы один файл журнала. Для файлов журнала транзакций рекомендуется расширение LDF.

Например, простая база данных с именем Sales включает один первичный файл, содержащий все данные и объекты, и один файл журнала, содержащий сведения журнала транзакций. Более сложная база данных с именем Orders может содержать один первичный файл и пять вторичных файлов. Данные и объекты внутри базы данных распределяются по всем шести файлам, а четыре файла журнала содержат сведения журнала транзакций.

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

Логические и физические имена файлов

Файлы SQL Server имеют два типа имен файлов.

logical_file_name: имя, используемое для ссылки на физический файл во всех инструкциях Transact-SQL. Логическое имя файла должно соответствовать правилам для идентификаторов SQL Server и быть уникальным среди логических имен файлов в соответствующей базе данных.

os_file_name: имя физического файла, включающее путь к каталогу. Оно должно соответствовать правилам для имен файлов операционной системы.

Дополнительные сведения об аргументах NAME и FILENAME см. в статье Параметры ALTER DATABASE ((Transact-SQL)) для файлов и файловых групп.

Файлы данных и файлы журналов SQL Server могут использоваться как в файловой системе FAT, так и в системе NTFS. В системах Windows рекомендуется использовать файловую систему NTFS по причинам ее большей безопасности.

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

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

Размер файла

Файлы SQL Server могут автоматически увеличиваться в размерах, превосходя первоначально заданные показатели. При определении файла пользователь может указывать требуемый шаг роста. Каждый раз при заполнении файла его размер увеличивается на указанный шаг роста. Если в файловой группе имеется несколько файлов, их автоматический рост начинается лишь по заполнении всех файлов.

Дополнительные сведения о страницах и их типах см. в разделе Руководство по архитектуре страниц и экстентов.

Кроме того, можно указать максимальный размер каждого файла. Если максимальный размер файла не указан, файл может продолжать увеличиваться в размерах, пока не займет все доступное место на диске. Эта функция особенно полезна в случаях, когда SQL Server используется в качестве базы данных, внедренной в приложение, где пользователь не имеет удобного доступа к системному администратору. По мере необходимости пользователь может предоставить файлам возможность увеличиваться в размерах автоматически, тем самым снимая с администратора часть забот по наблюдению за свободным пространством базы данных и по распределению дополнительного пространства вручную.

Дополнительные сведения об управлении файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.

Файлы моментального снимка базы данных

Вид файла, используемый для хранения копируемых во время записи данных моментального снимка базы данных, зависит от того, создается ли моментальный снимок пользователем или используется внутренними механизмами.

Данные моментального снимка базы данных, созданного пользователем, хранятся в одном или нескольких разреженных файлах. Технология разреженных файлов является свойством файловой системы NTFS. Изначально разреженный файл не содержит данных пользователя, и место на диске под него не выделяется. Общие сведения об использовании разреженных файлов в моментальных снимках базы данных и о том, как растут моментальные снимки базы данных, см. в разделе Просмотр размера разреженного файла моментального снимка базы данных.
Моментальные снимки базы данных могут использоваться внутренними механизмами при выполнении определенных команд DBCC. Эти команды включают DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKALLOC и DBCC CHECKFILEGROUP. Внутренним моментальным снимком базы данных используются разреженные дополнительные потоки данных исходных файлов базы данных. Подобно разреженным файлам, дополнительные потоки данных являются свойством файловой системы NTFS. Использование разреженных дополнительных потоков данных позволяет связать несколько расположений данных с одним файлом или папкой, не затрагивая при этом размер файла или статистику тома.

Файловые группы

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

Например, Data1.ndf , Data2.ndf и Data3.ndf могут быть созданы на трех дисках соответственно и отнесены к файловой группе fgroup1 . В этом случае можно создать таблицу на основе файловой группы fgroup1 . Запросы данных из таблицы будут распределены по трем дискам, и это улучшит производительность. Подобного улучшения производительности можно достичь и с помощью одного файла, созданного на чередующемся наборе дискового массива RAID. Тем не менее файлы и файловые группы позволяют без труда добавлять новые файлы на новые диски.

Все файлы данных хранятся в файловых группах, перечисленных в следующей таблице.

Файловая группа	Описание
Первичная	Файловая группа, содержащая первичный файл. Все системные таблицы являются частью первичной файловой группы.
Данные, оптимизированные для памяти	В основе оптимизированной для памяти файловой группы лежит файловая группа файлового потока.
Файловый поток
Определяемые пользователем маршруты	Любая файловая группа, созданная пользователем при создании или изменении базы данных.

Файловая группа по умолчанию (первичная)

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

Файловая группа PRIMARY является группой по умолчанию, если только она не была изменена инструкцией ALTER DATABASE. Системные объекты и таблицы распределяются внутри первичной файловой группы, а не новой файловой группой по умолчанию.

Файловая группа данных, оптимизированных для памяти

Дополнительные сведения об оптимизированных для памяти файловых группах см. в разделе Оптимизированные для памяти файловые группы.

Файловая группа файлового потока

Дополнительные сведения о файловых группах файлового потока см. в статьях FILESTREAM и Создание базы данных с поддержкой FILESTREAM.

Пример файлов и файловых групп

В следующем примере создается база данных на основе экземпляра SQL Server. База данных содержит первичный файл данных, пользовательскую файловую группу и файл журнала. Первичный файл данных входит в состав первичной файловой группы, а пользовательская файловая группа состоит из двух вторичных файлов данных. Инструкция ALTER DATABASE придает пользовательской файловой группе статус файловой группы по умолчанию. Затем создается таблица, определяющая пользовательскую файловую группу. (В этом примере используется универсальный путь к c:\Program Files\Microsoft SQL Server\MSSQL.1 , чтобы не указывать версию SQL Server.)

Данная иллюстрация обобщает все вышесказанное (кроме данных файлового потока).

Стратегия заполнения файлов и файловых групп

В файловых группах для каждого файла используется стратегия пропорционального заполнения. При записи данных в файловую группу компонент Компонент SQL Server Database Engine записывает в каждый файл количество данных, пропорциональное свободному пространству этого файла, вместо записи всех данных в первый файл до его заполнения. Затем запись производится в следующий файл. Например, если в файле f1 свободно 100 МБ, а в файле f2 — 200 МБ, то в файл f1 записывается одна часть данных, а в файл f2 — две части, и так далее. Таким образом, оба файла будут заполнены примерно в одно и то же время, и достигается простейшее распределение данных между хранилищами.

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

Правила проектирования файлов и файловых групп

Для файлов и файловых групп действуют следующие правила:

файл или файловая группа не могут использоваться несколькими базами данных. Например, файлы sales.mdf и sales.ndf, содержащие данные и объекты базы данных sales, не могут использоваться никакой другой базой данных.
файл может быть элементом только одной файловой группы;
файлы журнала транзакций не могут входить ни в какие файловые группы.

Рекомендации

Рекомендации при работе с файлами и файловыми группами:

Для большинства баз данных достаточно использовать один файл данных и один файл журнала транзакций.
При использовании множества файлов данных создайте вторую файловую группу с дополнительным файлом и сделайте ее файловой группой по умолчанию. Тогда в первичном файле будут храниться только системные таблицы и объекты.
Чтобы увеличить производительность, по возможности разнесите файлы и файловые группы по нескольким доступным дискам. Объекты, активно конкурирующие за свободное пространство, поместите в разные файловые группы.
Используйте файловые группы для целенаправленного размещения объектов на конкретных физических дисках.
Помещайте разные таблицы, использующиеся в одних и тех же запросах с соединениями, в разные файловые группы. Этот этап увеличит производительность, так как для поиска соединяемых данных можно будет использовать параллельный ввод-вывод.
Часто используемые таблицы и некластеризованные индексы, относящиеся к ним, помещайте в разные файловые группы. Использование разных групп файлов увеличит производительность, так как можно будет использовать параллельный ввод и вывод, если файлы находятся на разных жестких дисках.
Не помещайте файлы журнала транзакций на тот же физический диск, где находятся другие файлы и файловые группы.
Если необходимо расширить том или раздел, в котором находятся файлы базы данных, с помощью таких средств, как Diskpart, следует сначала выполнить резервное копирование всех системных и пользовательских баз данных и остановить службы SQL Server. Кроме того, после успешного расширения томов дисков рекомендуется выполнить команду DBCC CHECKDB , чтобы обеспечить физическую целостность всех баз данных в томе.

Дополнительные рекомендации по управлению файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.

Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.

1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".

Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.

1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)

Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.

3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).

При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.

5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.

Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Просмотр записей таблиц, к сожалению, не реализован.

На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.

Файл MDF является основным файлом базы данных в SQL Server. Как все мы знаем, Microsoft SQL Server является наиболее предпочтительной системой реляционных баз данных, хранящей миллионы записей каждый день. В такой ситуации повреждение файла SQL MDF может представлять высокий риск для организаций. Если файл MDF поврежден, SQL Server не сможет получить доступ к файлу данных. Поэтому необходимо восстановить поврежденный файл MDF. Этот блог расскажет вам, как выполнить восстановление MDF файла? Прежде чем перейти к процессу, мы должны сначала знать причины коррупции.

Что является причиной повреждения файла MDF?

Существует несколько возможных причин, по которым файл SQL MDF поврежден. Здесь мы обсудим некоторые из причин:

Повреждение хранилища, на котором хранятся все файлы MDF.
Если пользователь сохранил базу данных SQL в сжатой папке, существует вероятность, что файл MDF будет поврежден.
Любые изменения будут внесены в учетную запись SQL Server.
Пользователь может случайно удалить данные.
Если заголовок файла поврежден, он повредит файл MDF.
Использование базы данных SQL с сетевой ошибкой приведет к повреждению файла MDF.
Сбой жесткого диска, вирусная атака, внезапный сбой питания, внезапное отключение системы

Способ 1: Восстановить поврежденный файл MDF с помощью DBCC CHECKDB

Шаг 1. Сначала запустите DBCC CHECKDB в поврежденной базе данных SQL, используя следующую команду:

DBCC CHECKDB (Name of the corrupt Database)

Шаг 2. Теперь проверьте идентификатор индекса и рассмотрите следующие два случая соответственно

Случай 1: Если ID индекса> 1, удалите его и создайте заново.
Случай 2: Если ID индекса равен 0 или 1, снова запустите DBCC CHECKDB и используйте параметры восстановления, такие как

DBCC CHECK (name_of_corrupt_database, repair_fast)

DBCC CHECK (name_of_corrupt_database, repair_rebuild)

DBCC CHECK (name_of_corrupt_database, repair_allow_data_loss)

Метод 2: Восстановление MDF файла с помощью Инструмент восстановления SQL

В случае сбоя ручного метода вы можете выбрать программное обеспечение Восстановление SQL. Это 100% безопасное и полезное приложение для восстановления и восстановления файла MDF. Это помогает пользователям восстановить все элементы данных, такие как таблицы, правила, триггеры, функции и многое другое. Инструмент прост в использовании и предоставляет различные расширенные функции, которые даже полезны для непрофессиональных пользователей.

Выполните следующие простые шаги для восстановить поврежденный файл MDF в SQL Server 2019, 2017, 2016, 2014, 2012:

Шаг 1. Загрузите и запустите программное обеспечение

Шаг 2. Нажмите «Открыть» и выберите файл MDF для восстановления.

Шаг 3. Выберите параметр сканирования, а затем вручную или автоматически выберите версию .mdf файла SQL Server.

Шаг 4. После завершения процесса сканирования вы можете легко увидеть предварительный просмотр восстановленных данных. Удаленные записи базы данных SQL будут показаны красным цветом. Теперь нажмите на опцию экспорта сверху.

Шаг 5. Выберите «Параметры экспорта» из «Экспорт в базу данных SQL Server» и «Совместимые сценарии SQL Server». После заполните необходимые данные.

Шаг 6. Выберите базу данных назначения из «создать новую базу данных» и «экспортировать в существующую базу данных» в соответствии с необходимостью.

Шаг 7. Выберите опцию Экспорт только со схемой и Со схемой и данными. После этого нажмите кнопку «Экспорт».

Дополнительные функции программного обеспечения восстановление MDF файла

Восстановление поврежденный файл базы данных SQL со всеми объектами, такими как таблицы, триггеры, функции, правила и т. Д.
Расширенная опция для предварительного просмотра удаленных записей базы данных SQL в красном цвете.
Нет проблем с размером файла, номером файла и потерей данных при восстановлении поврежденного файла MDF.
Поддерживает SQL Server 2017, 2016, 2014, 2012, 2008 и все другие версии.
Восстановить поврежденный файл MDF и восстановить данные непосредственно в действующей базе данных SQL Server, используя только учетные данные вашей учетной записи SQL Server.
Восстановить файл базы данных SQL в новую базу данных или существующую базу данных без каких-либо изменений.
Работает со всеми последними и более ранними версиями ОС Microsoft Windows, включая Windows 10, 8, 7 и т. Д.

Последние строки

Данные всегда важны для всех нас, и повреждение файла базы данных SQL MDF может вызвать проблемы у пользователей. Чтобы преодолеть и решить проблему повреждения, здесь мы объяснили руководство и автоматизированное решение восстановить поврежденный файл базы данных SQL. Может быть трудно выполнить восстановление MDF файла вручную, потому что это требует сильных технических знаний, а иногда и не устраняет повреждение. По этой причине рекомендуется выбрать автоматическое решение для быстрого и безопасного результата.

в основном я следовал учебник и решил удалить .mdf файл после этого.

моя строка подключения выглядит следующим образом:

Я пробовал смотреть на Обозреватель объектов SQL Server, но он выглядит следующим образом:

кроме того, в Обозревателе серверов я не см. любые подключения к данным.

и когда я пытаюсь добавить новое подключение в Обозревателе серверов я не вижу никаких баз данных с именем OdeToFoodDb .

извините за этот широкий вопрос, но я новичок в Entity Framework и не совсем понимаю, что здесь не так.

Edit Этот ответ был принят потому что это подтверждает ошибка и обходной путь, используемый OP (переименование базы данных может помогите). Я полностью согласен с тем, что переименование базы данных на самом деле не является приемлемым способом, и не полностью решает проблему. К сожалению, я не проверил другие способы действительно решить ее в SSMS.

Я думаю, что для локальной БД SQL Server вы не должны использовать Initial Catalog собственность. Я предлагаю использовать:

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

из консоли диспетчера пакетов запустите:
sqllocaldb.exe stop v11.0
sqllocaldb.exe delete v11.0
запуск проекта
регистрация пользователя

удалите эту строку из строки подключения, которая должна это сделать ;) "Ключевое слово attachdbfilename=|параметр datadirectory|whateverurdatabasenameis-ХХХХХХХХХХ.МДФ"

в Обозревателе серверов добавить новое подключение к базе данных
Выберите файл базы данных Microsoft SQL Server в качестве источника данных
выбрать имя базы данных, как это должно быть в соответствии с строку подключения в web.конфигурации
был создан новый файл базы данных, и в Обозревателе серверов появились два подключения к базе данных: "MyDatabaseName" и " MyDatabaseName (Имя_моего_проекта)"
удалить одно соединение (я удалил "MyDatabaseName")

У вас уже есть старая копия базы данных, установленные в Обозревателе серверов. Таким образом, это простое столкновение имен в Обозревателе объектов сервера / SQL server. Вероятно, вы уже создали то же имя каталога базы данных, прежде чем решили переместить его в папку Apps_Data. Так что имя базы данных уже существует и просто должно быть удалено.

просто зайдите в Visual Studio > View > SQL Server Object Explorer и удалите старое имя базы данных и ее соединение. Повторите попытку приложения еще раз и он должен установить .mdf-файл в App_Data и снова создайте ту же самую точную базу данных в Проводнике сервера.

согласно @davide-icardi, удалите "Initial Catalog=xxx;" из интернета.config, но также проверьте, чтобы ваш файл профиля публикации azure также удалил его отсюда:
[Youraspnetproject path]\Properties\PublishProfiles[YourAspNetProjectName].pubxml

выше cmd показывает имена экземпляров, включая 'v11. 0'

Если экземпляр уже запущен, введите в подскажите

Если состояние не запущено или остановлено, запустите экземпляр с помощью

и извлечения же информация, что и выше.

в диалоговом окне SS Management Studio 'Connect' введите

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

готово! Как только он исчезнет, VS У EF не должно быть проблем с его воссозданием.

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

У меня была та же ошибка при выполнении учебника по "начало работы с ASP.NET MVC 5 / Microsoft Docs". Я был на Visual Studio 2015. Я открыл View - > SQL Server Object Explorer и удалил базу данных, названную в честь учебника, тогда она могла бы работать. смотрите удалить .mdf файл из app_data вызывает исключение не удается прикрепить файл в качестве базы данных

восстановить базу данных. Не удалять его и ваше приложение должно продолжать работать.

странно, по той же проблеме, что помогло мне был изменения в версии 11.0 в следующем разделе конфигурации.

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

когда я удаляю базу данных из первых двух точек, ошибка все равно возникает. Итак, мне также нужно было удалить базу данных из Обозревателя объектов SQL Server. Тогда я мог бы легко запустить команду "update-database" без ошибок. Надеюсь, это поможет.

просто измените имя базы данных от web.уровень проекта конфигурации файл, а затем обновить базу данных.

connectionString = источник данных =(LocalDb)\MSSQLLocalDB;AttachDbFilename=| / DataDirectory / \aspnet-имя проекта-20180413070506.mdf"; Initial Catalog ;интегрированное

измените жирную цифру на какое-то другое число:

connectionString = данные Источник==(на localdb)\MSSQLLocalDB;ключевое слово attachdbfilename ; Initial Catalog ;интегрированное

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

Читайте также: