1с 77 ошибка блокировки открытия базы данных

22.06.15 — 10:40

1 — 22.06.15 — 10:44

+

да, одну только песенку не спел шаман — убить «общий» 1cv7.lck; но сейчас уже куча народу позаходили, это не вариант (в обед буду пробовать).

Но опять же, если проблемы были бы с ним — никто бы ВООБЩЕ зайти не смог, не так ли?…

2 — 22.06.15 — 10:44

Бубен, только шаманский бубен.

Нет денех на бубен — окропи святой водой сервер, мот тоже помочь

3 — 22.06.15 — 10:44

(1) нет

4 — 22.06.15 — 10:45

(1)

1. Размер самого большого ДБФ — в студию.

2. Что говорит ТИИ выполненное на КОПИИ базы?

5 — 22.06.15 — 10:49

(4)

1. 1SENTRY.DBF — 450 Мб

2. как раз делаю, жду

(3) :)) «нет» — в каком смысле? я правильно думаю, что битый 1cv7.exe никому бы не дал вообще войти?

6 — 22.06.15 — 10:49

(5) Чего битый ?

7 — 22.06.15 — 10:50

8 — 22.06.15 — 10:51

(7) спешишь

🙂

9 — 22.06.15 — 10:51

(6) предположительно (а может, и вовсе не битый)

я к тому, что имеет ли смысл рассматривать это как рабочую гипотезу?

10 — 22.06.15 — 10:52

Короче, уволить админа и ТС, загнать всех в терминал, наслаждаться.

11 — 22.06.15 — 10:52

(9) нет

12 — 22.06.15 — 10:54

(10) все и так загнаны в терминал

а так — приезжай (удаленку руководство не рассматривает:)) — работы всем хватит:))

13 — 22.06.15 — 10:55

Расскажу свою историю — авось натолкнет на идеи. У меня поутру стартует отдельный сеанс на терминальном сервере для обмена Моби-С. И в настоящее время иногда выгрузка завершается ошибкой и молчаливым закрыванием 1С. После чего робот увидев безобразие пытается запустить 1С заново, но при этом вылазит ошибка «ошибка блокировки открытия базы данных» — при этом 1С в списке процессов не появляется и никто в 1С попасть не может. Пришлось научить робота при появлении этого окна — принудительно завершать сеанс терминального пользователя, и повторный запуск этого сеанса — позволяет работать безо всяких ошибок (до следующего вылета МобиС).

14 — 22.06.15 — 10:56

(7) через Блокнот?

15 — 22.06.15 — 11:00

Ну давай, рассказывай:

на каком серваке лежит база,

куда смотрят темпы

как ты настроил «архивирование»

как заходят юзвери (со своим каталогом или без)

какой контейнер создан под дисковую систему

какой хоть релиз платформы

16 — 22.06.15 — 11:01

какие вк используются для работы

ломанная ли 1с-ина или ищет ключ по всей сети

17 — 22.06.15 — 11:13

18 — 22.06.15 — 11:21

19 — 22.06.15 — 11:27

Ну, помимо того, что не известно, что за сервер, и так видно , что самое узкое место — дисковая система.

Всё на одном физ. диске (еще не известно что это — массив из дисков (и какой ?) или просто один винт) — и система и базы и архив. Нормально, че..

20 — 22.06.15 — 11:28

Ну а про делание архивов «таким способом», скромно промолчу.

ЗЫ: половины архивов нема же, да ?

🙂

21 — 22.06.15 — 11:29

гм…в процессе колупания на сервере, прибил там 4 процесса CNAP2LAK (я думал, что поборол их окончательно — недавно тут темку тоже стартовал — но вот не всех гадов вычистил, оказывается), которые полностью сожрали ресурсы проца. Теперь симптомы данной темы пропали — пользователь заходит быстро, сообщение-сабж не вылетает. Такое ощущение, что из-за нехватки ресурсов проца при каждом входе загрузка таблиц растягивалась надолго — и если пересекались два таких входа, у одного вылетала блокировка.

Но изначально, когда с утра начались проблемы, проц вроде не был сожран…….

22 — 22.06.15 — 11:32

(20) а что не так со способом? архивы вроде делаются без сбоев, все есть — я просто не сказал, что следующий батник (запускается через полчасика) переименует файл savedb1c.zip, добавляя к нему текущую дату.

А вот насчет того что все на одном физическом диске — да, это правда….Причем я только счас сам увидел, что первый физ.диск «Не распределен». Походу, рэйд, который до меня еще настраивали, сделан криво. Придется в субботу выходить, колупаться:((

23 — 22.06.15 — 11:40

(17) как-то мутно сформулировано

24 — 22.06.15 — 11:55

Что мешает архивировать папку 1С средствами zip?

25 — 22.06.15 — 12:01

(24) а почему не средствами конфигуратора? помимо религиозных предрассудков…

Постоянно разворачиваем бэкапы — все ок…

26 — 22.06.15 — 12:04

(25) ТИИ уже закончилось? Кстати попробуй в копии убить mlg. Несколько раз именно из-за ошибок в нем были проблемы с запуском 1С.

(21) этот файлик — судя по всему часть софта от Кэнона.

Кэнон отличается умом и сообразительностью.

Убивай по Кэнону лишенее что не надо для оперативной работы

1Cv8.1CD — Файл данных достиг максимального размера!  8
 1С выдает предупреждение » Файл данных достиг максимального размера» .
Подскажите из — за чего это и как можно решить ?
Превышен размер файла, обычно это сообщение возникает, когда размер файла 1Cv8.1CD приближается к 10 гигабайтам или размер ка

Cообщение: «Не удалось удалить чеки ККМ!»  2
  Пользователь с правами Администратор ККМ проводит Закрытие кассовой смены (Z).
Выходит сообщение: » Не удалось удалить чеки ККМ!»
ФР печатает Z -отчет, но Отчет о рознчничных продажах не формируется.
Необходимо дать роли Администратор ККМ прав

Microsift Visual C++ Runtime Library Program …1cv77s.exe abnormal program termination  0
 При запуске 1С 7.7 выдает сообщение:
Microsift Visual C++ Runtime Library Program C:Program Files1Cv77BIN1cv77s.exe abnormal program termination
Вариант 1. Обычно это происходит, когда повреждается файл регистрации. Точнее, когда не дописывает

PostgreSQL: установка, настройка, обслуживание  11
  PostgreSQL напрямую «из коробки» применяться для использования с 1С Предприятем не может. Необходима именно адаптированная версия от 1С, превращающая PostgreSQL в блокировочник, причем нужно понимать, что блокировки будут накладываться на всю таблиц

Битая ссылка, <Объект не найден>, Уникальный Идентификатор, GUID  70
 Когда кто-то удаляет данные из базы без проверки ссылок на эти объекты, то везде где этот объект использовался появляется сообщение вида: Объект не найден (84:bf5600145e3710ab11dda4c605dbe824) .
https://helpf.pro/uploads/img/_1-46z7I4U7Ww.png
В

Посмотреть все результаты поиска похожих

Рисунок 1 – Ошибка блокировки данных

Ошибка блокировки данных происходит в программе 1С: Предприятия 7.7 в сетевой версии или когда данные хранятся на SQL сервере. Возникает она обычно в случае, когда файлы заблокированы кем-то из пользователей, первым вошедшим в монопольный режим.

Рисунок 2 – Запуск 1С в монопольном режиме

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

Рисунок 3 – Запуск 1С в режиме Монитор

Рисунок 4 – Открытие окна активных пользователей через Монитор

Теперь, в окне активных пользователей, мы видим кто занял приложение в монопольном режиме.

Рисунок 5 – Активные пользователи

Еще одной причиной невозможности получить доступ к базе данных может являться «неполный запуск» приложения. Например, пользователь выбрал базу, но не указал логин и пароль, а окно входа осталось открытым, и система в этом момент заблокировала доступ. Тогда в мониторе увидеть кто именно хотел войти в базу будет нельзя. Выход из ситуации на компьютере, где расположены файлы с базой. Необходимо открыть Панель управления / Администрирование / Управление компьютеров / Служебные программы / Общие папки и там посмотреть подключенные сеансы (Рис. 6) и открытые файлы (Рис. 7).

Рисунок 6 – Подключенные сеансы

Рисунок 7 – Открытые файлы

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

Случается, что при работе с программой 1С возникает подобная ошибка — ошибка блокировки данных:

Чаще всего данное предупреждение конфигуратора возникает при выгрузке информационной базы или при обновлении конфигурации 1С. Для того чтобы исправить сложившуюся ситуацию и запустить работу конфигурации, в первую очередь необходимо выяснить причины ошибки исключительной блокировки информационной базы. Это может быть одна из следующих причин:

• Пользователи не вышли из системы 1С

Для начала необходимо посмотреть все активные сеансы пользователей. Активных пользователей можно посмотреть в конфигураторе 1С так: нажать кнопку Администрирование, затем выбрать Активные пользователи. И попросить их выйти из системы. Также информацию о блокирующих сеансах обычно можно получить из самого окна с ошибкой.

• У пользователя запущена база 1С, но не введен пароль

В таком случае у пользователя остается висеть подобное окно:

Сеанс такого пользователя найти сложнее, так как он не отображается в окошке Активные пользователи. Более того, информация об ошибке не содержит какой-либо полезной информации:

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

• Зависшие сеансы

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

Способы завершения зависших сеансов в файловом варианте

• С помощью Диспетчера задач. При завершении сеансов информация у пользователей, работающих в системе, может не сохраниться, и важные данные могут быть потеряны. Завершить сеансы данным способом можно так: вызвать диспетчер задач (Ctrl+Alt+Delete), затем нажать снять задачу, затем завершить процесс. Процессы 1С называются 1Сv8.exe или 1Сv8c.exe.

• Перезагрузить сервер, на котором установлена файловая система 1С

Способы завершения зависших сеансов в клиент-серверном варианте

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

• Выделить нужные зависшие сеансы и удалить их через пункт контекстного меню;

*Если в меню Сеансы нет сеансов, их стоит поискать в меню Соединения. И попробовать аналогично удалить.

• Если не удалось удалить сеансы, используя консоль, то необходимо перезапустить службу Агент сервера 1С:Предприятия 8.3.
• Если все предыдущие способы не решили проблему и зависшие сеансы так и остались на своих местах, то в качестве крайней меры необходимо перезагрузить сервер.

Зависшие фоновые задания в клиент-серверном варианте

В клиент-серверном варианте частым источником возникновения ошибки исключительной блокировки информационной базы являются повисшие фоновые задания.

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

Чтобы их удалить можно попробовать следующие способы:

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

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

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

Ошибка происходит при запуске 1C 7.7 сетевой или SQL–версии, которые могут запускать в монопольном и разделённом режиме, и может иметь различные причины.

1. Из-за того, что другим экземпляром программы уже открыта эта конфигурацию. Для устранения проблемы нужно открыть Монитор Пользователей, посмотреть, кто заблокировал БД и попросить его выйти.

• 1С уже запущена в монопольном режиме. Проверка – запустить 1С в режиме Монитор и посмотреть пользователей.
• Кто-то пытался входить в 1С и не довел дело до конца (выбор базы, выбор пользователя, пароль) – а система временно заблокировала что-то. Если режим Монитор не помог, то см. пункт 2 про файлы LCK.
• Кто-то был в 1С в монопольном режиме и вышел совсем недавно (несколько секунд нужно на закрытие всех файлов и снятие всех блокировок). Решение – подождать 30 сек и повторить вход.
• Кто-то получил доступ к одному из файлов базы данных напрямую, без 1С, и не отпускает его.

Решение для Windows – на компьютере, где хранятся файлы базы данных зайти Панель управления – Администрирование – Управление компьютером – Служебные программы – Общие папки и там посмотреть, кто вошел и какие файлы открыл.
Решение для WINE@Etersoft — перезапустить Самба-сервер.

1. На SQL-версии такая ошибка может появляться, когда кто-то из пользователей наблюдает за работой БД 1С через средства SQL-сервера. Монитор тут не поможет. Нужно средствами SQL-сервера определить, кто обращается к БД и закрыть эти приложения (или прервать блокировки средствами SQL сервера). После этого монопольный доступ к БД станет возможен.
2. Также возможно, что в каталоге пользователя после последнего сбоя (и, возможно, каталоге базы) остались временные файлы 1cv7.LCK. Если причина в этом, то достаточно будет удалить такие файлы.

На днях столкнулся с одной ошибкой SQL. Попробовал все варианты исправления, и на уровне 1С и на уровне самого SQL, даже индексы хотел было перестроить. Но помогла банальная перезагрузка (физически) сервера.
Но по пути накопал вот этот список ошибок и их решений. В будущем может пригодиться!

Источник

Причины сообщения «Ошибка блокировки открытия базы данных»

Такое сообщение может возникнуть при блокировке файла users.usr. В этот момент у кого-то из пользователей может быть открыто окно ввода логина и пароля. Довольно часто такое сообщение возникает при массовом входе в программу.

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

Duplicate key в таблице _1scrdoc

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

Восстановление базы только из 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 = ‘<db_name>’

5. Перезапускаем SQL Server

6. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты. Заходим в EM, выбираем базу, снимаем галку Restricted access в свойствах базы.

7. Из QA выполняем

DBCC REBUILD_LOG(‘<db_name>’, ‘<имя нового лога с указанием полного пути>’)
SQL Server скажет — Warning: The log for database ‘<db_name>’ has been rebuilt.

8. Если все нормально, то там же выполняем

Use master
go
sp_dboption ‘<db_name>’, ‘single_user’, ‘true’
go
USE <db_name>
GO
DBCC CHECKDB(‘<db_name>’, REPAIR_ALLOW_DATA_LOSS)
go

9. Если все в порядке, то

sp_dboption ‘<db_name>’, ‘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), а движения существуют. Вот и происходит ошибка. Лечение — восстановить флаг 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) по умолчанию для данного логина:

sp_defaultdb ‘user_name’,’master’

Какой выбрать сервер/сеть & etc для работы 1С на SQL Server Сервер двухпроцессорный , память минимум 256 (лучше больше, SQL память любит, и юзает ее грамотно)

Дисковая подсистема. Минимум 2 винта, лучше SCSI. Почему 2 — потому что нам RAID нужен. Для бедных — программный (кстати в NT 1 и 3! RAID хорошо реализован), для богатых — железный. Официальные рекомендации Microsoft для больших, сильно нагруженных БД SQL: 2 диска (RAID1) — система, от 3 дисков (RAID5) — сама БД, 2 диска (RAID1) — для журналов транзакций.

Сеть можно и 10, хотя лучше 100 М. Хороший вариант — сетевые карточки Intel или 3Com, которые могут работать в команде (режим отказоустойчивости или повышения пропускной способности). Хотя мы используем просто 2 карточки: половина офиса ходит на одну, вторая половина людей на вторую. На какой адрес ходить, устанавливается в Client Network Utility.

Как производить проверку, переиндексацию базы на SQL Server

Проверку логической целостности нужно выполнять штатными средствами 1С:Предприятия (Тестирование и исправление ИБ). В случае, если такую проверку не удается выполнить, следует проверить физическую целостность БД средствами MS SQL.
Для проверки целостности средствами MS SQL нужно выполнить следующую команду: DBCC CHECKDB (‘<имя базы>’,REPAIR_REBUILD)
Перед выполнением этой команды нужно базу данных перевести в режим «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-файлы остались. Можно ли поднять базу?

exec sp_attach_db <имя БД>,<путь к файлу *.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.