При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:
Каталог не обнаружен ‘v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’
по причине: Каталог не обнаружен ‘ConfigSavee0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’
по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Журнал транзакций для базы данных «acc_main» переполнен. Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
Идем на сервер и первым делом проверяем место на дисках,
А оно закончилось нужно потом почистить хард или увеличивать объем, а пока порежем лог
Открываем SQL Server Management Studio
Это ошибка Microsoft SQL Server — переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек( где acc_main — название базы Бух)
Код SQL
USE acc_main
ALTER DATABASE acc_main SET RECOVERY SIMPLE
DBCC SHRINKFILE (acc_main, 50);
ALTER DATABASE acc_main SET RECOVERY FULL
Результат выполнения:
Тоже самое можно сделать вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files) — установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to) — указать приемлемый размер лога.
Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Полная(Full) — OK.
В дополнении скажу, что можно сохранить лог в файл и выполнить шринк так(BaseDB — имя базы данных):
Код SQL
BACKUP LOG BaseDB TO DISK = '<D:BackupBase_Log.trn'
DBCC SHRINKFILE (BaseDB_Log, 20) WITH NO_INFOMSGS
Все
Проблемы
Ошибка во время выполнения «-2147217900 (80040e14)»: [Microsoft] [драйвер SQL Server ODBC] [SQL Server] в запросе используются операторы внешнего соединения, не относящиеся к ANSI («* =» или «= *»). Чтобы выполнить этот запрос без изменения, установите для свойства уровень совместимости текущей базы данных значение 80 или ниже, используя sp_dbcmptlevel хранимой процедуры. Настоятельно рекомендуется переписать запрос с использованием операторов внешнего соединения ANSI (левое ВНЕШНее соединение, ПРАВОе ВНЕШНее соединение). В будущих версиях SQL Server операторы соединения, не относящиеся к ANSI, не поддерживаются даже в режимах обратной совместимости, эта ошибка возникает в одном из следующих трех экземпляров.
-
FDM 6,0 и 7,0 — ошибка в ФИНАНСОВом масштабе в формате строки для базы данных SQL 2005.
-
FRL13, FDM 6,0 и 7,0 — ошибка при запуске мастера отчетов для базы данных SQL 2005.
-
Отчеты с эталонными кодами, TREF, TPROJ получать ошибки для SQL 2005 DB.
Статус
Этот SMR был исправлен в пакете обновления для R07670 и последующих пакетах обновления, а также на веб-сайте (www.FRxSoftware.com) для обеспечения доступности пакетов обновления для главной книги. Вы также можете зарегистрироваться для автоматического уведомления о службах на нашем веб-сайте.
Обходное решение
Чтобы обойти эту ошибку, выполните указанные ниже действия, чтобы установить уровень совместимости базы данных в 80:
-
В корпоративном диспетчере щелкните правой кнопкой мыши базу данных. Выберите пункт Свойства.
-
Откройте вкладку Параметры.
-
Измените уровень совместимости на 80.
Ссылки
Нужна дополнительная помощь?
Нужны дополнительные параметры?
Изучите преимущества подписки, просмотрите учебные курсы, узнайте, как защитить свое устройство и т. д.
В сообществах можно задавать вопросы и отвечать на них, отправлять отзывы и консультироваться с экспертами разных профилей.
Ошибка СУБД Microsoft SQL Server Native Client 11.0: «Журнал транзакций для базы данных переполнен». Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
Описание ошибки:
В это публикации будет рассмотрена не только сама ошибка СУБД о переполнении журнала транзакций, но описание того, как уменьшить (очистить, сократить) журнал транзакций.
Найденные решения:
Эту ситуацию можно было отнести к части обслуживающих операций. Но дает знать о себе переполнение журнала транзакций СУБД в самые неподходящие моменты. Например, часто, при обновлении баз данных, поскольку частое выполнение операций по модификации данных базы приводит к увеличению размеров журнала транзакций. Старые записи журнала транзакций в некоторый момент могут стать не востребованными и могут быть удалены. Таким образом освобождается место для новых записей. Если вовремя не удалять старые записи журнала транзакций, то его файл может занять все свободное дисковое пространство и работа с базой данных станет невозможной, сопровождаемая приведенной ошибкой.
Рассмотрим
Еще примеры того, как сократить журнал регистрации см. в публикации посвященной непосредственно этому вопросу в разделе часто задаваемых вопросов.
Рассмотрим один из примеров того, как сократить журнал транзакций.
Запускается SQL Server Management Studio. В ветке «Базы данных» дерева «Обозревателя объектов» находим базу данных по названию. Вызываем контекстное меню правой кнопкой мыши и в нем выбираем пункт «Создать запрос» и вводим текст:
BACKUP LOG [name_db] WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE ([log_file])
go
, где [name_db] — имя (название) базы данных СУБД. В примере — «Бухгалтерия»;
, а [log_file] имя или путь к файлу журнала (лога) транзакций формата *.ldf. О том, как определить его название и местоположение см. ниже, в примере — «Бухгалтерия_log.ldf»
Прежде чем «Выполнить» запрос нажатием соответствующей кнопки потребуется определить имя файла журнала транзакций. Можно просто искать его по названию базы и расширению на дисках сервера. А можно посмотреть в свойствах базы.
Для этого через то же контекстное меню, что уже вызывали ранее, переходим в «Свойства» базы данных SQL.
В открывшемся окне «Свойств базы данных» переходим на страницу «Файлы». И смотрим «Путь» и «Имя файла» журнала транзакций в колонках таблицы «Файлы базы данных». Эти сведения и используем для заполнения в запросе для параметра [log_file].
Так же можно на будущее настроить автоматическое сжатие журнала транзакций. Это изложено в документации на сайте SQL: настройка авторасширения и автосжатия в SQL Server
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
04-08-2021
Журавлев А.С.
(Сайт azhur-c.ru)
I have an admin page to search for products to edit, but the page keeps returning the error:
Microsoft OLE DB Provider for SQL Server error ‘80040e14’ Ambiguous
column name ‘prod_id’. /__admin/searchproducts.asp, line 89
I’m unsure why this error is cropping up, because the page and site is a direct copy of another website and associated MSSQL database and the search product page works on that site.
This is the code in question (not sure if it will be easy to read here though);
if request("fldSubmitted") <> "" then
if request("fldprodid") <> "" and isNumeric(request("fldprodid")) then
SQL = "select * from products where prod_id = " & cdbl(request("fldprodid"))
else
SQL = "select "
if request("showtop") <> "all" then
SQL = SQL & " top " & request("showtop") & " " & replace(replace(request("orderby")," asc","")," desc","") & ", "
end if
SQL = SQL & "prod_name, prod_id, prod_code, prod_icon, prod_thumb, prod_numViews, prod_archived"
if request("fldLabel") <> "" then SQL = SQl & ", label_name"
if request("fldCat") <> "" then SQL = SQL & ", cat_name"
if request("fldSubcat") <> "" then SQL = SQL & ", subcat_name"
SQL = SQL & " from products"
if request("fldLabel") <> "" then SQL = SQL & ", labels"
if request("fldCat") <> "" then SQL = SQL & ", categories"
if request("fldSubcat") <> "" then SQL = SQl & ", subcategories"
sql = sql & " where 1=1"
if request("fldLabel")<> "" then SQL = SQL & "and prod_label = label_id "
if request("fldCat") <> "" then SQL = SQL & "and prod_category = cat_id "
if request("fldSubcat") <> "" then SQL = SQL & "and prod_subcategory = subcat_id "
if request("fldName") <> "" then SQL = SQL & " and (prod_name like '%" & replace(request("fldName"),"'","''") & "%')"
if request("fldCode") <> "" then SQL = SQL & " and (prod_code like '%" & replace(request("fldCode"),"'","''") & "%')"
if request("fldLabel") <> "" then SQL = SQL & " and prod_label = " & request("fldLabel")
if request("fldCat") <> "" then SQL = SQL & " and prod_category = " & request("fldCat")
if request("fldSubcat") <> "" then SQL = SQL & " and prod_subcategory = " & request("fldSubcat")
if request("fldArchived") = "No" then
SQL = SQL & " and prod_archived = 0"
if request("instock") = "No" then SQL = SQL & " and prod_numleft > 0"
end if
SQL = SQL & " order by " & request("orderby")
end if
25.05.18 — 00:16
Одна из конфигураций на базе SQL при входе начала выдавать следующую ошибку:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: The transaction log for database ‘Base_Name’ is full due to ‘LOG_BACKUP’.
HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
1 — 25.05.18 — 00:19
Так так, очень интересно. А ты?
2 — 25.05.18 — 00:28
(1) Попытался урезать лог транзакций через SQL server, но вышла и там ошибка:
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed. (Microsoft SQL Server, Error: 3023)
3 — 25.05.18 — 00:33
(2) Очень интересно. Что думаешь делать?
4 — 25.05.18 — 00:33
(1) Тоже самое если делать это с помощью запроса:
Msg 3023, Level 16, State 2, Line 2
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed.
Msg 5069, Level 16, State 1, Line 2
ALTER DATABASE statement failed.
Msg 8985, Level 16, State 1, Line 3
Could not locate file ‘acc_main’ for database ‘Base_Name’ in sys.database_files. The file either does not exist, or was dropped.
5 — 25.05.18 — 00:34
(3) У Вас есть какие то идеи?
6 — 25.05.18 — 00:38
(5) Я уж думал не спросишь
Скуль перегружать пробовал?
7 — 25.05.18 — 00:43
(6) Перезагружал SQL server agent, но не помогло
8 — 25.05.18 — 00:45
(7) Причем здесь агент, просто скуль перегружал?
9 — 25.05.18 — 00:45
У базы стоит модель Full или Simple?
10 — 25.05.18 — 00:48
(8) Сейчас попробую. (9) Модль Фулл пытался сделать Симпл, но выдает ошибку которую я написал выше
11 — 25.05.18 — 00:59
(8) Кажись заработало! Ввел две команды net stop mssqlserver и net start mssqlserver и база запустилась! Спасибо большое)
12 — 25.05.18 — 08:17
Отлично
13 — 25.05.18 — 08:24
база в фулле, шел бекап лога транзакций, ты убил сервер во время этого процесса — четко, могешь.
Теперь попробуй всё таки снять бекап лога транзакций и снять/увеличить ограничение по максимальному размеру лога транзакций.
Если тебе не нужен лог транзакций — переведи базы в simple.
14 — 25.05.18 — 08:27
Роман, а как часто тебя заказчики бьют за советы как в (6) не разбирающимся разработчикам?
15 — 25.05.18 — 09:57
(14) У меня такого не бывает, я базы сразу в Simple перевожу
Можно привести хоть один пример, где в 1С может пригодиться Full?
16 — 25.05.18 — 10:00
(14) Про бэкап речь зашла только после (0), а в (0) речь не о бэкапе, а о переполнении лога
17 — 25.05.18 — 10:31
>>Можно привести хоть один пример, где в 1С может пригодиться Full?
ЛОЛ, да везде, где заказчики не готовы терять данные за период от предыдущего полного бэкапа до сбоя.
18 — 25.05.18 — 11:20
(17) Ты про ситуацию, когда клиент реально готов восстанавливать все максимально полно и ежечасные инкрементные бекапы по необъяснимой причине ему так же не подходят
А я про реальность
И в моей реальности полный бекап плюс ежечасные инкрементные полностью закрывают потребность в бекапах
В этом случае Full только жрет место и все
19 — 25.05.18 — 11:32
(18)
>>ежечасные инкрементные бекапы по необъяснимой причине ему так же не подходят
не по необъяснимой, а по причине что он готов потерять макс. 15 минут — именно такой интервал можно ставить для бэкапа лога, для дифф. бэкапа в конце дня у тебя дифф бэкап просто не будет успевать делаться за это время
>>В этом случае Full только жрет место и все
Ты просто не умеешь настраивать бэкап лога. Твои ежечасные диф. бэкапы точно так же жрут место, по сравнению с бэкапами лога.
Насчет инкрементного, как ты говоришь, бэкапа (на самом деле он называется дифференциальный) — у него есть серьезный подводный камень — сделанный админом или сторонними средствами полный бэкап делает невалидной всю цепочку твоих бэкапов.
20 — 25.05.18 — 11:34
>>А я про реальность
Ты живешь в какой-то своей реальности, в моей реальности все продакшн базы в фулл модели.
21 — 25.05.18 — 12:07
(19) В общем, я не понял, в чем проблема полных бекапов + дифференциальных, в случае ручного восстановления этого более чем достаточно
22 — 25.05.18 — 12:14
(21) Печенюшка, с таким уровнем понимания тебя нельзя до баз больше 15 Мб допускать, бгг
23 — 25.05.18 — 12:40
(19) > Насчет инкрементного, как ты говоришь, бэкапа (на самом деле он называется дифференциальный) — у него есть серьезный подводный камень — сделанный админом или сторонними средствами полный бэкап делает невалидной всю цепочку твоих бэкапов
COPY ONLY спасает, но кто про него вспоминает )
24 — 25.05.18 — 13:51
(22) Ой, Миша, дурачок, я и не признал тебя сразу, сорян :))
X Leshiy
25 — 25.05.18 — 14:12
(17) >>ЛОЛ, да везде, где заказчики не готовы терять данные за период от предыдущего полного бэкапа до сбоя.
Раз заказчик такой нежный, пусть строит репликацию)))