Ожидание блокировки таблицы "Журналы", хотя никто ничего не делает ??!!
Часто возникает такая ситуация, в базе возникает ошибка: Ожидание блокировки таблицы "Журналы", хотя никто ничего не делает, и никто ничего не может сделать из-за ошибки. И пока все юзеры не выйдут, ошибка не исчезает. Подскажите, пожалуйста, можно-ли решить эту проблему без выхода пользователей? И может кто знает из-за чего это может происходить?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(9) где проверить? И у кого?
Если я так понял, имеете ввиду права пользователей, которые подключились к удаленному рабочему столу, и причем здесь могут быть эти права, если люди работают какое-то время, а потом бац и ожидание транзакции у всех, никто ничего не может сделать.
Если я так понял, имеете ввиду права пользователей, которые подключились к удаленному рабочему столу, и причем здесь могут быть эти права, если люди работают какое-то время, а потом бац и ожидание транзакции у всех, никто ничего не может сделать.
(16) насколько я помню в распределенной БД обмен идет через конфигуратор и в монопольном режиме, пользователи в этот момент работать не могут????
предлагаю попробовать тестирование и исправление БД+сжатие, если не поможет, то попробовать создать новую базу и загрузить в нее данные из старой
предлагаю попробовать тестирование и исправление БД+сжатие, если не поможет, то попробовать создать новую базу и загрузить в нее данные из старой
На моей прошлой работе такая ошибка возникала в случае переполнения таблицы журнала. Уже не помню, как конкретно файл назывался, но один из тех, которые начинаются с 1s. Причина простая - таблица DBF имеет ограничение по размеру файла и по количеству записей (. При попытке записать сверх этого количества 1Ска у текущего пользователя подвисает с такой ошибкой, а у остальных просто висит в ожидании захвата таблицы. Не ваш случай?
1. Проверить размер файлов в базе. Не должно быть ни одного dbf/cdx больше гига. Исключение, пункт 2
2. Проверить не используется ли какой-то нестандартный "движок". Типа
3. Какой-нибудь неспешный отчёт может давать блокировку общего журнала.
4. Возможна зависшая блокировка после аварийного завершения у кого-то 1Ски.
2. Проверить не используется ли какой-то нестандартный "движок". Типа
3. Какой-нибудь неспешный отчёт может давать блокировку общего журнала.
4. Возможна зависшая блокировка после аварийного завершения у кого-то 1Ски.
(26)
Неправильный ответ. Невозможно корректно работать на типовой 1С с DBF большими гига. Движок не способен. Больше гига начинаются проблемы, притом, на сколько помнится, именно на блокировках. Больше двух гигов и 1С ничего с этим файлом сделать не может. Может просто не запуститься.
А обрезать базу всегда возможно. Даже если очень-очень не хотят все. От высшего руководства до последнего кодера. Или перейти на SQL. И почти навечно забыть о ограничении размеров.
файлы больше 1 гига есть, сделать их меньше гига невозможно.
Неправильный ответ. Невозможно корректно работать на типовой 1С с DBF большими гига. Движок не способен. Больше гига начинаются проблемы, притом, на сколько помнится, именно на блокировках. Больше двух гигов и 1С ничего с этим файлом сделать не может. Может просто не запуститься.
А обрезать базу всегда возможно. Даже если очень-очень не хотят все. От высшего руководства до последнего кодера. Или перейти на SQL. И почти навечно забыть о ограничении размеров.
(29) Меньше 1 гига сделать невозможно регистр Покупатели, я подрезку делаю каждые полгода, оставляю итоги только 1 последний год, и это уже 1,4 ГБ, причем это без ввода начальных остатков, подрезку делаю сторонней программой (просто тупо обрезаю полгода, если еще ввод начальный остатков сделать тогда база превысит 2 ГБ). Пробывали перейти на SQL - запустили обработку, которая переводит файловую в SQL - ждали 2 месяца, не дождались когда закончиться, в итоге бросили эту затею.
(33) Перевод на SQL тоже делают частями, потому что полная выгрузка базы, которую можно заливать как правило превышает ограничения файловой системы.
Выпочковывают распределенку с миграцией только справочники, база только получатель, заливают в SQL, заменяют мд-шник на полную миграцию и доливают данные по периодам(месяц, неделя,день, минимальный чтоб не тормозило), перезапись документов всех без перепроведения. Когда данные в периферийной SQL будут полностью синхронизированы, можно будет прописать пути у пользователей на новую базу за минуту. В периферийной базе работать нельзя до полной синхронизации, движения должны быть из данных ЦБ.
Выпочковывают распределенку с миграцией только справочники, база только получатель, заливают в SQL, заменяют мд-шник на полную миграцию и доливают данные по периодам(месяц, неделя,день, минимальный чтоб не тормозило), перезапись документов всех без перепроведения. Когда данные в периферийной SQL будут полностью синхронизированы, можно будет прописать пути у пользователей на новую базу за минуту. В периферийной базе работать нельзя до полной синхронизации, движения должны быть из данных ЦБ.
(33)
За подробностями - к уважаемому hogik, или сразу сюда, чтобы не искать:
На всякий случай - там даны ссылки на другие варианты решения (от того же автора):
Меньше 1 гига сделать невозможно регистр Покупатели
Тогда без решения этой проблемы бесполезно что-то еще предпринимать: при совместном (многопользовательском) режиме работы 1С 7.7 на файлах больше 1 Гб ведет себя непредсказуемо.
За подробностями - к уважаемому hogik, или сразу сюда, чтобы не искать:
На всякий случай - там даны ссылки на другие варианты решения (от того же автора):
Пробывали перейти на SQL - запустили обработку, которая переводит файловую в SQL - ждали 2 месяца, не дождались
А переходили, наверное, "с наскока", не обращая внимания на размер базы? Возможно, что и тут вся проблема в нем, можно попробовать:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот