На днях столкнулся с одной ошибкой SQL. Попробовал все варианты исправления, и на уровне 1С и на уровне самого SQL, даже индексы хотел было перестроить. Но помогла банальная перезагрузка (физически) сервера.
Но по пути накопал вот этот список ошибок и их решений. В будущем может пригодиться!
Причины сообщения «Ошибка блокировки открытия базы данных»
Такое сообщение может возникнуть при блокировке файла users.usr. В этот момент у кого-то из пользователей может быть открыто окно ввода логина и пароля. Довольно часто такое сообщение возникает при массовом входе в программу.
Также такое сообщение могут вызвать зависшие файловые блокировки в каталоге базы. Это может быть связано с проблемами сети. Помочь может перезагрузка сервера.
Duplicate key в таблице _1scrdoc
Удаление повторяющихся ключей с помощью метода описанного в статье может не помочь. При пересчете такие записи могут появиться вновь. Для решения проблемы можно применить следующую методику — создаете пустую базу в нее копируете файл конфигурации, заходите в конфигуратор, удаляете все графы отбора, сохраняете, копируете файл конфигурации в рабочую базу, запускаете пересчет служебных данных, восстанавливаете графы отбора. Все должно работать.
Как добавить информационную базу 1С на сервер MS SQL
Восстановление базы только из MDF
1. Создаем новую базу с таким же именем и такимиже по именам и расположению .mdf и .ldf файлами
2. Останавливаем сервер, подменяем файл .mdf
3. Стартуем сервер, не обращаем внимания на статус базы
4. Из QA выполняем скрипт
Use master
go
sp_configure ‘allow updates’, 1
reconfigure with override
go
4.Там же выполняем
update sysdatabases set status= 32768 where name = »
5. Перезапускаем SQL Server
6. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты. Заходим в EM, выбираем базу, снимаем галку Restricted access в свойствах базы.
7. Из QA выполняем
DBCC REBUILD_LOG(», »)
SQL Server скажет — Warning: The log for database » has been rebuilt.
8. Если все нормально, то там же выполняем
Use master
go
sp_dboption », ‘single_user’, ‘true’
go
USE
GO
DBCC CHECKDB(», REPAIR_ALLOW_DATA_LOSS)
go
9. Если все в порядке, то
sp_dboption », ‘single_user’, ‘false’
go
Use master
go
sp_configure ‘allow updates’, 0
go
Ошибка violation of pirmary key при загрузке в базу УРБД
Симпотмы: При загрузке репликации в переферийную базу, SQL вылетает с ошибкой:
Violation of PRIMARY KEY constraint ‘PK_RA4047’. Cannot insert duplicate key in object ‘RA4047’
Лечение: Для решения данной проблемы отработана следующая технология. Запускаем SQL Profiler с регистрацией ошибок. Когда появляется ошибка смотрим последние операторы, определяем IDDOC сбойного документа. Проблема в том, что признак проведенности по регистру у документа снят (флаг RF), а движения существуют. Вот и происходит ошибка.
Уроки SQL для начинающих / #1 — Что такое SQL? Установка локального сервера
Лечение — восстановить флаг RF и признак проведенности документы. Можно конечно удалить движения, но не факт, что это правильно отразится на итогах в регистре.
После переноса базы с одного сервера на сервер при попытке подключиться к ней выдается сообщение: Server: Msg 916, Level 14, State 1, Line 1 Server user «user_1c» is not a valid user in database «CV7DB»
sp_change_users_login AUTO_FIX, ‘user_1c’
«Cannot open user default database». Using master database instead
Это сообщение может возникнуть в том случае, если база данных, которая когда-то была базой по умолчанию для некоторого пользователя, была удалена или в текущий момент недоступна. Тем не менее данная ситуация может привести к тому, что логин станет заблокированным и не сможет подключится к любой другой БД на данном сервере. Для того, чтобы исправить эту ситуацию нужно задать другую БД (например, master) по умолчанию для данного логина:
Какой выбрать сервер/сеть single user»: sp_dboption »,’single user’,true.
В процессе работы DBCC CHECKDB могут быть обнаружены ошибки и часть может быть сразу же исправлена. Если ошибки остались, то по всей видимости их нельзя восстановить без потери некоторых данных. В этом случае нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS (перед запуском желательно сделать копию файлов базы данных). DBCC CHECKDB (»,REPAIR_ALLOW_DATA_LOSS)
После выполнения DBCC CHECKDB нужно не забыть вернуться в нормальный режим (выйти из режима «single user»): sp_dboption »,’single user’,false.
Переиндексацию базы данных на MS SQL не нужно делать так часто, как в случае с DBF-версией 1С:Предприятия (например, при аварийном завершении работы пользователя). MS SQL автоматически поддерживает индексы в актуальном состоянии. Пересоздавать индексы имеет смысл в одном из следующих случаев:
1) Индекс физически поврежден. Это случается довольно редко и для восстановления нужно использовать вышеупомянутый DBCC CHECKDB.
2) Страницы индекса сильно фрагментированы и требуется их упорядочить.
3) Нужно изменить степень заполнения индексных страниц (fill factor).
4) Требуется изменить тип индекса (кластерный/некластерный). При использовании 1С это обычно неактуально.
Для пересоздания индексов следует воспользоваться командой: DBCC DBREINDEX (») или запустить хранимую процедуру, которая переиндексирует все таблицы в базе данных: EXEC _1sp_DBReindex
Время от времени возникает проблема «Доступ к базе на сервере возможен только из одного каталога информационной базы». Как лечить?
Диагноз: Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации.
Анамнез: После закрытия 1С на сервере NT освобождаются ресурсы, которые занимал пользователь. Однако в случае некорректного завершения работы не останавливается SQL-процесс, запущенный пользователем.
Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “ManagementCurrent ActivityProcess Info”. Надо найти в списке справа процесс, который мешает Вам жить, выделить его и в меню “Action” выбрать пункт “Kill Process”
Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид PIPEMSSQL$NAMEDSERVERSQLquery.
Если вышеизложенное слишком сложно для Вас, Вы можете просто перегрузить SQL server. Надо только убедиться, что ни одна другая програма не использует его в этот момент.
Если ошибка возникает постоянно, имеет смысл проверить правильность установки конфигурации: с одной базой данных на сервере пользователи должны работать из одного каталога с конфигурационными файлами. Иначе говоря, не могут одновременно работать две (даже идентичные) конфигурации, размещенные в разных каталогах и ссылающиеся на одну и ту же базу.
Умер SQL, но mdf и ldf-файлы остались. Можно ли поднять базу?
Ошибка SQL Server «Cannot resolve collation for equal operation»
Данная ошибка возникает при сравнении полей с различной collation. Подробно описание ошибки можно найти в статье «Transact-SQL ReferenceData TypesCollation Precedence» в Books OnLine. В случае 1С это может быть, например, когда различаются collation вашей рабочей базы и базы tempdb. При первоначальной установке collation базы tempdb устанавливается такой же как у сервера и обычно не меняется.
Collation базы выбирается при создании базы, но может быть изменена с помощью команды ALTER DATABASE. Поэтому обычно такая ошибка возникает, когда collation базы первоначально была выбрана отличной от collation сервера. База tempdb используется для создания временных таблиц, в частности, когда используется конструкция «В» в запросе или когда используется отбор по группе в других выборках.
Чтобы устранить эту ошибку нужно поменять либо collation рабочей базы, либо collation сервера. Чтобы поменять collation рабочей базы воспользуйтесь командой ALTER DATABASE COLLATION = collation_сервера. При этом сами данные не изменяются. Поэтому необходимо сначала выгрузить ваши данные, а потом загрузить обратно.
Я, например, делал это с помощью инструмента Data Transformation Services (DTS) с помощью задачи переноса объекто SQL Server с сервера на сервер. Для этого нужно создать новую базу с collation равной collation сервера, в параметрах задачи (на рабочем поле кликнете правой клавишой мышки, выберите «Disconnected Edit», затем ветку задач, вашу задачу переноса) нужно указать дополнительную опцию ScriptOptionEx = SQLDMOScript2_70Only(16777216), которая укажет не формировать для каждого поля его collation (чтобы не переносить старую). Затем нужно выполнить задачу. Все. Теперь можете пользоваться новой базой, либо загрузить данные обратно.
Про дополнительную опцию можно прочитать в статье «Data Transformation ServicesUsage Considerations in DTSData Conversion and Transformation Considerations».
Ошибка «Could not continue scan with NOLOCK due to data movement»
В BOL причина ошибки связана с сочетанием блокировки (NOLOCK) и уровнем изоляции (READ UNCOMMITED) таким образом, что при чтении данных некоторые прочитанные страницы могут быть удалены до завершения транзакции. Нам это ничего не дает. Кажется, что проблема связана с проектированием 1С. На самом деле система использует другой уровень изоляции, который не может привести к такой ситуации.
Обычно ошибка появляется при разрушении данных. На моей памяти это было в двух случаях. Проверка БД производится как обычно с помощью DBCC CHECKDB. Если данные разрушены, то команда выдаст список объектов, в которых найдены повреждения. Сделайте резервную копию и попытайтесь с помощью все той же DBCC CHECKDB восстановить данные.
Если повреждения несерьезные, то восстановление проходит гладко. Если нет, то проще произвести восстановление БД из резервной копии.
Совет. Чтобы не возникало данной ошибки, следите за местом на диске, следите за состоянием вашей дисковой системы, ставьте на сервер ИБП, делайте резервные копии.
Каким образом на клиентской рабочей станции можно настроить сетевой протокол (TCP/IP, Named Pipes и т.д.) взаимодействия с сервером MS SQL?
Для этого нужно воспользоваться вышеупомянутой утилитой Client Network Utility. С помощью нее можно настроить тип протокола (TCP/IP, Named Pipes, Multiprotocol и т.д.), а также ряд дополнительных параметров (например, при успользовании протокола TCP/IP можно указать порт, по которому будет производиться подключение к серверу MS SQL).
Как устранить ошибку «База не может быть открыта в однопользовательском режиме»?
Данная ошибка происходит при попытке войти в 1С монопольно, при этом в текущий момент к этой базе есть открытые соединения (не 1С). Первое — закройте все приложения, которые могут использовать эту базу. Это могут быть Enterprise Manage, Query Analyzer, SQL Profiler.
Можно не их закрывать, а проделать, например, следующие действия: EM — сделать Disconnect для сервера, QA — выбрать другую базу в списке, Profiler — закрыть все трейсы. Второе — для устранения этой проблемы нужно закрыть все открытые подключения к этой базе. Для получения информации о том, кто в данный момент подключен к базе, в Enterprise Manager 2000 есть раздел Management Current Activity Process Info.
Login failed for user XXX. Reason: Not associated with trusted SQL Server connection
1С поддерживает только смешанный режим подключения к SQL Server. Для установки режима подключения в свойствах сервера на закладке Security выберите Mixed mode.
При выгрузке-загрузке 1С зависает, либо вылетает
Одной из причин (довольно распространенной) является наличие реквизитов неограниченной длины. Например, такие рквизиты обычно присутствуют в общих реквизитах документа (Комментарий). При выгрузке такие реквизиты должны стоять в конце списка реквизитов. Если все же ошибка не устраняется, то поробуйте удалить эти реквизиты и произвести выгрузку-загрузку без них.
Еще один универсальный совет — при загрузке в строке состояния пишется загрузка какого объекта производиться. Если на этом объекте 1С зависла или вылетела, то попробуйте произвести выгрузку без этих объектов — для этого их нужно удалить из базы. Конечно это не выход, но все же таким образом вы убедитесь, что причина именно в этом виде объектов, что поможет вам локализовать причину ошибки.
И конечно же самое первое, что вы должны сделать перед выгрузкой это тестирование базы. Подробно про переход на весрию SQL 1С (в том числе про выгрузку-загрузку) вы можете прочитать в этой статье.
Восстановление базы данных только из MDF
1. Создаем пустую базу с_тем_же_именем, остановливаем сервер и записываем вместо «родного» файла этой базы свой *.mdf.
2. Запускаем сервер. Он переведет базу в suspect.
3. Выводим базу из состояния suspect:
use master
go
sp_configure ‘allow updates’,1
go
reconfigure with override
go
—Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
update sysdatabases set status=32768 where name=’Base_New’
go
—А теперь запретим прямое изменение системных таблиц:
sp_configure ‘allow updates’,0
go
4. База находится в «emergency mode», поэтому копируем данные из этой базы в новую, используя режим «Copy objects and data, between SQL Server databases».
Автор ответа Джинн, neatmen
База находится в состоянии suspect. Как ее «оживить»?
use master
go
sp_configure ‘allow updates’,1
go
reconfigure with override
go
—Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
update sysdatabases set status=32768 where name=’Base_New’
go
—А теперь запретим прямое изменение системных таблиц:
sp_configure ‘allow updates’,0
go
При запуске 1С для SQL базы 1С закрывается без всяких сообщений. С одним пользователем работает, с другим нет
Например, под администратором работает нормально, а под другими пользователями нет. Я встречал такую ситуацию уже два раза. Оба раза 1С не запускалась вообще. Причина была банальной — на папке с базой стояли права только на чтение. Кто-то вообразил себя супер вумным админом и решил — раз БД лежит на SQL, то зачем что-томенять в каталоге ИБ? Поставил права только на чтение и забыл.
Права могут стоять не обязательнона папке, могут стоять на md или другом файле или только для определенных пользователей.
Других причин «безмолвного» закрытия 1С не встречал. Были случаи когда рушился mlg файл (лог действий)или вообще конфа рушилась. Но в этих случаях обычно выдается сообщение с предложением «сходить к Microsoft».
Проблемы при соединении с SQL Server установленном на Windows 2003 Server
Обычно выдается сообщение «SQL server does not exist or access denied» несмотря на все настройки , доступность сервера и т.п. По текущим сводкам с полей проблему решает установка SP 3a.
Источник: mudritskiy.blogspot.com
данный вариант программы не может работать с sql базой #317714
На кой новый каталог? Надо платформу для СКЛ поставить и всё. Она и с ДБФ будет работать.
#7 by anna3388
спасибо, сейчас с админом переговорю
Источник: avprog.ru
Соединение с сервером баз данных разорвано администратором или Неопознанная ошибка HRESULT=80004005
Вот некоторые способы, которые помогут решить данную проблему:
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду “Проверка конфигурации” с установленным флажком “Проверка логической целостности конфигурации”. При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С – это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.
2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)
вот пример работоспособности этого приема
http://partners.v8.1c.ru/forum/thread.jsp?id=543293
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
Взято с http://www.forum.mista.ru/topic.php?id=465608
можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]
5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.
6) Ошибка :»Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005″
Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)
Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб.
А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется. Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки — все ОК.
У Вас есть свое решение!? оставьте его в комментариях)
Источник: helpf.pro