Я так понимаю, что, когда 7.7 снимается аварийно, то если в системе в этот момент нет других пользователей, при следующем запуске придется переиндексировать, а если есть - то не придется. Нельзя ли как-нибудь по другому избежать переиндексации после аварийного снятия?
Ситуация следующая: в организации стоит 7.7, с подключенными внешними компонентами частного производства (документации нет, помощи ждать неоткуда). В частности, ВК (видимо) аварийно снимает сеанс при отсутствии активности в течение времени больше заданного. В будни все нормально, все активно работают, даже если и выкинет кого - все ок. А в выходные зайдет пользователь, забудет сеанс выключить - снялся аварийно, переиндексируйте базу. Либо всем права на монопольный вход давать (но не хочется), либо что-то придумать. Если открыть сеанс админа - не помогает, через часа 4 снимется аварийно, разве что еще запрогать мышку двигать.
Нет какого-нибудь гениального решения?

dbfку чистить...

(1) можно чуть подробнее? которую и где чистить?

сделать батник, который будет запускать конфигуратор в пакетном режиме и индексировать базу не?

При запуске отказаться от индексации.

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

(4) тогда приходится отказаться и от запуска...

(6) переходи на сиквельную :-)
(0) почему сеанс админа падает?

вообще-то переиндексация после аварийного случая бывает НУЖНА! иначе можешь на грабли налететь...

не хочешь переиндексацию - переходи на скуль

(7) переход на сиквельную сейчас нереален. внешние компоненты, скрипты, трогать не надо. готовим переход на 8.2, надо просто дожить
сеанс админа снимается (судя по всему) подключенной самодельной внешней компонентой.

(8) а что за грабли могут быть? вроде, если в течение дня все работают, кого-то сняли аварийно - зашел заново, все нормально.
как бы систему обмануть, чтоб она думала, что кто-то в базе есть - нет способа?

можно по 1cusers.dbf смотреть нужна ли переиндексация

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

(8) Полностью поддерживаю! Когда индесы по-настоящему летят - очень весело становится.

(12) нет, сеанс работает, конфигуратор 7.7 живет, 8-ка живет, а пользовательская сессия 7.7 убивается

(12)так и я о том же...
Судя по всему, дело в банальном соотношении радиусов, а не в таинственных компонентах...

(13) чего будет-то? про что смеяться?

Перевести базу на SQL, там это реализовано.

(0) Дизассемблировать компоненту, посмотреть вызов завершения процесса - и за NOP'ить.

(17) не будем, писал выше
(18) до этого еще не дорос я...

(0) Если на SQL переходить не планируете, смотри в сторну V7DBNet. Для небольшого количества пользователей (не помню сколько) - решение бесплатное...

(10) несталкивался когда индексы слетают?

(19) была на просторах инета патчилка, которая в том числе и убирала запросы всякие

(10) нет. расскажите, чего ждать, а то пугаете как бабой-ягой...

+20  http://www.wirth.ru/load/v7dbnet/1-1-0-2

(22) боюсь, по такому описанию патчилку я на просторах нета не найду...

рабочий день - долгий.. утром первый юзер, запустивший 1с, получает отлуп и звонит ТС, как администратору БД.. если он пришел на работу.

далее Администратор1С запускает в монопольном режиме и ждет вместе с юзерами 45 секунд.
после чего работа начинается.

Короче На всё-про-всё в общей сложности, 1.5 - 2 минуты. Не стОит овчинка выделки

(25) а ты попробуй Как убрать вопрос о переиндексации?

(20), (24) спасибо, но надо просто дожить до перехода на 8.2 (пару месяцев). в базе работает одновременно до 100 юзеров, думаю, какой-то разгон производился (детали неизвестны), как будет то, что сделано, с дбнетом взаимодействовать - боюсь представить...

(26) понимаю, тему читать лень. речь идет про выходные. переиндексирование занимает 35 минут.
(25) то есть надо 1cusers.dbf удалить просто? а что будет, если я его попробую удалить, когда в базе кто-то сидеть будет, опа придет? я жеж, повторю, не знаю, когда кто сеанс забудет и срубится он аварийно

(26) 45 секунд? А 45 минут не хочешь?

(29) Есть время, когда в БД никого нет? Например, в 4-5 утра? Тогда можно запускать переиндексацию в это время, должно снять остроту проблемы... правда что-то придется сделать с автоматическим ответом на вопрос.

(31) Вопрос о переиндексации убирается предварительным удалением всех CDX.

(30) значится или есть незакрытые регистры, скорее всего...

а как можно батником проверить, есть ли активные пользователи в 1с? то есть, смотреть, если пользователей нет, а 1susers.dbf есть, то грохать его?

(23) реально механизм такой

при аварийном закритии есть шанс что индексы на редактируемый обьект не расчитан (обычно это последний документ).

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

(35) ясно, а когда в базе тьма пользователей сидит, то же самое происходит, когда одного выкидывает? то есть база может стать "чуть-чуть неактуальной"?

(0) del 1susers.dbf перед стартом 1С

(37) ага, уже нашел этот файлик, спасибо. только придется пытаться раз в какое-то время его удалить - если пользователей нет, он не дастся просто. я думаю, это проще, чем пытаться на все пользовательские ярлыки 1с-ки навешивать + del 1susers.dbf...

(36) может и бывает, по этому хотя-бы раз в день стоит переин7дексацию делать

(39) так делаем, ага. спасибо за помощь и тебе, и всем, кто откликнулся!

вот толку _таким_ "переходить на 8.2"?

(41) а что на 8.2 можно переходить только волшебникам, питающимся радугой и какающим бабочками? давай всех прогов 1с, кроме таких гениев, как ты, уволим, и фигня, что 90% организаций останутся без обслуживания. и кстати, можно конкретней насчет _таким_?

(42) "Изделие Михаил"))) имел ввиду, что как же Вы, уважаемый, будете биться-колотиться с 8.2, если банальный вопрос с 7.7, который решается 33-я способами, решить не можете?..))

(33) ни разу с большими базами не работал ? )))

(0) "А в выходные зайдет пользователь, забудет сеанс выключить"... Это лечится административным ресурсом. Проводи работу с такими пользователями, а кривые ВК у тебя уже есть + тебе хочется битых индексов для разнообразия в жизни?!
Индексируйся обязательно!!!
Проводи работу с пользователями. Тыкай на провинившихся при срочной потребности в базе, когда она нужна.

(35) Будто бы при упавшей транзакции такого не происходит, при этом, правда, сеанс не всегда вылетает, а вот индексы становятся неактуальными.

P.S. если компонента "следит" за работой пользователя, то повесьте скрипт, который будет имитировать нажатие какой-то комбинации клавиш, если некоторое время нет событий мыши или клавиатуры, а в меню 1С сделайте на эту "магическую" комбинацию вызов процедуры глобального модуля, которая ничего не делает.
P.P.S. можно ещё через обработку ожидания попробовать или автообновление формы - но имитация работы пользователя будет.

(44) с большими - нет. но вряд ли у ТС реально большая база.

(0) ТС, ты уверен что тебе это реально надо? Может правильнее устранить причину по которой сеансы отваливаются(анпример проблеммы с сетью)? Даже если ты зайдёшь по нормальной схеем непохо-бы произвести перерасчёт рагистров (помимо переиндексации).

но если очень нужно - достаточно смахнуть 1cusers.dbf - для файловой базы

(5) Зачем О_о ? Нужно батник запускать ночью, каждый божий день. Или переходить на SQL :)

(48) Да бывают пользователи аварийно закрываются :)

(51) у меня такое было только пока сеть глючила жёстко, поставил терминальный сервер - бонусом юзера получили выросшее быстродействие.

(52) А у нас постоянно, в терминале... После батник по ночам решил проблему утренней мемо паузы у бухов :)

+(52) Так что у вас еще все впереди :)

(41) Нифига ты не понимаешь. Там это уже реализовано!

(6) ЩИТО? Если на вопрос о переиндексации ответить "Нет" - запустится без переиндексации

Удалить 1susers.dbf не достаточно. Глюки будут на непереиндексированной базе. Достаточно зайти в любой из журналов документом и побегать по нему в базе, где не сделана переиндексация. Сразу видны эти глюки.

Так что надо удалить 1susers.dbf и *.cdx перед запуском, тогда база автоматически переиндексируется без всяких вопросов.