Повреждение файла структуры чека. : УКМ-2

Э-э-э нет, батенька.. глюки происходят именно при ПЕРВОЙ загрузке. Все сервисные функции срабатывают тоже только при первом запуске. Т.е. делается бэкап, потом инициализация УКМ, потом ошибка, потом восстановление из бэкапа и после этого всё нормально работает. Пока наблюдаю, посмотрим, повторится эта бадяга или нет..

При запуске кассы проверяется 1-й запуск сегодня или нет, если первый то выполняется если нет - то нет....

Интересно, просто. Я када батники писал, долго думал как лучше зделать. Остановился на варианте файлов-флагов на сетевом диске. Если есть, например, файл time01.in на диске N, значит делаем синхронизацию времени на 1-й кассе. После успешного завершения, файл удаляем. У тебя как?

В батнике вызывается программуля (описание ниже)
DAY.EXE-проверяет наличие фала соответствующего текущей дате с заданным расширением. Возвращает
значение 666 если файл существует. Если не существует – создаёт его.
Например DAY.EXE B!
Если текущая дата 01.01.2009 и файл с именем “090101.!B” существует программа вернёт 666, иначе создаст
его.

надо проверить, что может быть такого в этих сервисных функциях, что могло бы менять среду запуска УКМ.

по ходу дела, после их отработки возможно чуть другое распределение свободной памяти, вызывающее труднопредсказуемые выверты поведения.
с такой фигней было бы очень просто бороться: после сервисных функций НЕ НАДО запускать укм. надо сразу уходить в ребут и получать уже вторую загрузку за день, без всякого сервиса: консервативное лечение синдрома первой загрузки! :)
попробуй, посмотри как повлияет. если ребутера под рукой нет - иди сюда:
бывают проще ребутеры, но они некошерные (ребут по прерыванию - два байта: CD 19 ; более злобный, ребут прыжком в биос - пять байт: EA F0 FF 00 F0)

только вот сильно подозреваю, что дело вовсе не в первой загрузке за день. наверняка, это еще и первый запуск укм после закрытия смены.
правда, как влияет закрытие смены - тоже понять не могу.
у тебя, случаем, автообрезка смен не включена? а то если нетерпеливые кассиры вырубают кассу не дождавшись окончания обрезки - может порушиться все, что хочешь, не только структура чека.
эту версию надо проверять как раз логированием выключения. или просто в stop.lst прописать создание флажка правильного выключения, а в автозагрузку - проверку его наличия: нашли - молча удалили и грузимся дальше; не нашли - запись в лог и красный свисток админу.

Ну да, первый не только за день, но и после закрытия смены. Но если бы при закрытии смены что-то прошло не так, то фиг бы касса вообще загрузилась, даже после восстановления из бэкапа. В бэкап ведь данные попадают ещё до первой инициализации УКМ. Олег прально на мысль натолкнул. Если у меня проверка структуры файловой системы стоит ПОСЛЕ бэкапа (что более вероятно по логике), то вполне возможно что scandsk.exe просто рушит таблицы по каким-то своим соображениям. Восстановление из бэкапа возвращает на место исправные таблички, но повторно проверка не запускается, т.к. она уже была в этот день. Ну вот типа так я думаю.
Вот это хорошая идея. Учитывая что данный функционал можно добавить в конфигурацию не вставая с места, я этим займусь обязательно. Ох как я буду зол, если кто-то не дожидается надписи, разрешающей выключение кассы.

не спрашивай почему, но это не так.

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

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

закончилась эта дребедень после того как:
1) вырубили автообрезку и начали регулярно резать руками на те же 60 смен.
2) обнаружили, что была какой-то заразкой включена оперсводка, которая не использовалась бэком. количество оперчеков ушло за 100тыс. выключили, старые оперчеки снесли.
3) прогнали scandisk и прибили lost&found цепочки
4) перебрали автозагрузку, оставили в памяти абсолютный минимум
5) переключили сетевого клиента на basic

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

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

З.Ы. От себя хочу добавить, что флэшки на кассах рекомендуется менять. Как часто, каждый решает сам, т.к. нагрузка на кассы может быть разная. Вполне возможно, что достигнут предел операций записи и некоторые блоки начинают глючить. Хуже другое. На убитых флэшках, через низкоуровневые программы типа MHDD и VICTORIA, не всегда видно битые блоки. Во всяком случае, у меня была одна флэшка с железно сбойными секторами, но этого не могла определить ни одна программа. Вы не представляете сколько я с этим лекспосом мучался! Потом допёрло, пошёл в магаз, купил обычную флэху для фотика, поменял, переставил софт и проблем больше не было.

З.Ы.Ы. Правда, при покупке лучше брать скоростные флэшки. Я взял обычную и при каждой операции записи касса слегка подвисает на пару секунд.