Добрый день, нужен совет намученных опытом граждан)
Имеется файловая 1Сv7, бухгалтерия для РБ. С недавнего времени стали происходить странные вещи, вот пара таких:
1. Построили оборотку, далее двойным кликом пытаемся провалиться в любую строку, но дальше показывает пустой отчёт. Ок, закрываем и ещё раз пытаемся провалиться, и так два-три раза и только потом корректно показывает данные. Также бывали случаи, когда не полностью попадают данные в ту же самую обработку, т.к. 1-2 документа словно их нет.
2. Иногда случается, при работе внутренней обработке (загрузка банковской выписки), она внезапно заканчивает работу и формирует документ наполовину загруженный. Хотя по окончании работы обработка должна выдать окно с предложением провести этот документ.
Пока критичного ничего не случилось, но это дело времени. Кажется, что с базой есть какие-то проблемы, что можно попробовать сделать?

если проблему удается воспроизвести - запускаем отладчик и смотрим что идет не так.

ТИИ на копии

(0) для начала, удалите все файлы *.cdx и зайдите монопольно, если не поможет, удалите 2 файла бух итогов и сделайте полный пересчет бух итогов

(2) воооттт этого не надо делать.

(3) :) это чем же на копии да повредит-то?

(4) ну если не жаль потраченного времени с неизвестным результатом, то пусть делает

размер какого-то dbf-файла превысил 1гб (или если используется кернел33х - 2Гб). судя по симптомам это скорее всего файл журнала документов (или проводок или отборов). в таких случаях процесс обработки (перебора результатов) любой выборки тупо прерывается если кто-то другой записывает данные в базу.
для проверки гипотезы - попробуй то же самое протестировать в монопольном режиме. если в монопольном режиме все работает корректно, а в разделенном "тоработает-тонеработает" -- значит оно (тем более если есть дбф-ки больше 1Гб)

(6)+: "что делать" в таких случаях:
1) на первых порах можно установить kernel33x (гуглвпомощь) - это решение "оттягивает конец" - т.е. предельный размер дбф-ки, при котором не возникают подобные косяки, с таким решением уже не 1гб а 2гб.
2) следующий необходимый шаг - обрезка базы и/или переход на скл.

(5) :) ну я согласен - там есть нюансы (можно исправить то что тии не делает) но попытка не пытка

(6) да, размер 1SENTRY.DBF перевалил за 1 Гб. Видимо подошло время обрезки БД. Спасибо за наводку, буду учить про Kernel3x.

Чтобы я правильно понял, после интеграции kernel33 появится возможность писать в таблицы пока они не вырастут до 2 Гб. После ничего уже не запишешь, выдаёт error 120. Эту ошибку уже не победить, останется только резать базу или SQL?

(10) Можно и больше 2Gb: https://gyazo.com/622763c039b65907291289f4c9ec1206
С dbeng32 от Wirth https://cloud.mail.ru/public/3mVX/4trK45on8
Это альтернативный движок работы с dbf, а не патч, которым является kernel33.
Только это уже не классический dbf получается, vfp его уже не прочтет. До 2Gb лучше не доводить.

(11) а какие подводные камни с новым движком могут быть, придётся код править? Как я понял достаточно просто заменить dbeng32.dll при старом kernel32?

(12) Никаких подводных камней не должно быть. Просто подменить библиотеку и все.
Бонусом еще идет снятие загрузки на процессор при блокировке. Возможно патчи ромикса по этому поводу будут конфликтовать.
Хотя кто-то писал что на ней стало вылетать, но там и 1с++ и formex древние были, но тот кто это сообщил так и не ответил закончились ли вылеты после обновления.
Но у меня лет 6 работает в терминале. В 3х конторах. И ничего такого из-за нее замечено мной не было.

+(13) Да, и kernel** ставить с ней тоже не надо.

(14) а что в вирте еще есть такого что в родном нет?

(15) А хрен его знает, что там еще может быть ;)
Но 2Gb+ и отсутствие 100% проца при блокировки там точно есть.
"Закладок" нет, не нашел, смотрел Гидрой от АНБ ;)

(16) там же вроде какое-топодобие в вирте клиент-сервера прикручено было. и даже кто-то и не один - юзали базы в таком варианте..?

(11):
codebase? не катит - там блокировки кривые. автор решения поэтому сам отказался.
advantage? там дфигища чего "по-другому".
или еще что-то? ссылку бы не кривую (не мылру и не гуандекс) плз?

(13) А если база изредка используется не только через терминал, то файл из dbeng32_wirth.7z для машин откуда изредка запускается база, а файл из dbeng32_wirth_nofb.7z на сервере/терминале?

(17) Да, было. Последний клиент/серверный и бесплатный v7dbnet https://cloud.mail.ru/public/4HaY/4D52dsiPC

(18) Протух сайт wirth.ru, давно протух. Что-то есть в архиве интернета, но темы с этим движком там нет.  И это не codebase и не avantage. Движок был переписан с нуля.

(19) Ну там я применил такой же патч, как и к оригинальному Подскажите про корректировку dbeng32.dll
По сетке библиотеку с таким патчем использовать нельзя.

(17) я юзаю давно и успешно.
(15) там много чего есть.
Сервер Вирт:V7DBNet – создан специально для работы с 1С:Предприятием 7.7, для повышения производительности работы
платформы в режиме DBF. Перевод 1С:Предприятия из режима блокировок в режим транзакций, а также кэширование данных на
стороне клиента, устраняет падение производительности 1С при работе по сети («проблема второго пользователя»). Файлы DBF не предоставляются в общий доступ, с ними работает только один сеанс – сервер, что позволяет не использовать специальных «серверных» операционных систем, а также снизить требования к «железу» сервера. Также тот факт, что файлы находятся на защищенной области диска, интересен с точки зрения политики безопасности организации.
Клиентская часть разработки перехватывает обращения к файлам DBF и CDX и передает запросы на сервер, сервер возвращает
результат в виде кэш-страниц. Далее клиент работает с такой страницей без обращения к серверу, пока сервер не сообщит о потере ее актуальности.
Для обеспечения надежности каждый сеанс работает с сервером через изолированную транзакцию, что помимо стабильности
обеспечивает полную параллельность доступа по чтению, даже если в данный момент происходит запись в таблицы.
Запись происходит также в отдельной изолированной транзакции, но поочередно. Клиент подает запрос серверу на запись, сервер добавляет его в очередь ожидания, или сразу дает разрешение. Сервер регулирует очередность записи, разделяя время между претендентами, сводя к минимуму «Ошибку блокировки транзакции». Также, для исключения неудачного захвата транзакции, в клиенте, стандартный вопрос 1С о невозможности захвата транзакции заменен на вопрос с автоповтором попытки через 3 секунды.
Если клиент сообщает, что он завершает запись успешно, и других измененных данных не будет, сервер отражает измененные
данные в файлах и фиксирует совою транзакцию. В случае неудачного завершения транзакции, она просто удаляется, никаких
изменений не происходит.

и это не всё. есть ещё, например, перенос индексов в отдельный каталог (на рам-диск), сообщения пользователям, определение кто блокирует, заверение сеансов, управление транзакциями на чтение или на запись, оперативная блокировка базы на новые подключения, определение необходимости реиндексации, исключение IDELETED из определённых таблиц.
это какой-то джедайский меч - выводит работу с клюшками на совершенно иной уровень, например можно работать через впн с достаточно узким каналом (4 мбит).
и главное - работает 1sqlite. есть конечно и проблемы, но за годы использования они более-менее изучены.