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

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

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

Оригинальный материал

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

Симпотмы:

При загрузке репликации в переферийную базу, SQL вылетает с ошибкой:
Violation of PRIMARY KEY constraint 'PK_RA4047'. Cannot insert duplicate key in object 'RA4047'

Лечение:

Для решения данной проблемы отработана следующая технология. Запускаем SQL Profiler с регистрацией ошибок. Когда появляется ошибка смотрим последние операторы, определяем IDDOC сбойного документа. Проблема в том, что признак проведенности по регистру у документа снят (флаг RF), а движения существуют. Вот и происходит ошибка. Лечение - восстановить флаг RF и признак проведенности документы. Можно конечно удалить движения, но не факт, что это правильно отразится на итогах в регистре.

Проблема SQL2000:
При перепровдении базы (например восстановление ГП) замеры показывают замедление проведения примерно в 1.5 раза на каждый месяц (по видам доков). Если выйти из 1С и запустить заново перепроведение базы, то скорость восстанавливается, но потом опять по понижающей. Памяти хватает, диски шустрые. Все замеры по просьбам делал - беда не найдена. Разные настройки базы/сервера тоже не помогли.

Помогла установка SQL 7.0 (с посл. SP6). (автор ответа Мурлин Дмитрий aka WWWolfy)

Есть также непроверенная информация, что данная проблема подтверждена в Microsoft и будет исправлена в следующих сервиспаках для SQL2000

Версия SQL Server храниться в переменной @@VERSION. Чтобы узнать ее содержимое выполните запрос SELECT @@VERSION в QA. Вот расшифровки номеров версий:

8.00.194 — Оригинальный SQL Server SQL Server 2000
8.00.384 — SP1
8.00.534 — SP2
8.00.760 — SP3

7.00.623 — Оригинальный SQL Server 7.0 или MSDE 1.0
7.00.699 — SP1
7.00.842 — SP2
7.00.961 — SP3
7.00.1063 — SP4