forum.clarionlife.net

Здравствуйте!
Сегодня на практике столкнулся с потерей записи в TPS. Произошло это, похоже, при обрыве сети. Небольшой магазин, два компьютера в соседних отделах соединены перевернутым шнуром. Ввод продаж через сканер штрих-кодов, приход грузится с дискеты. Нагрузка на базу небольшая. Размер TPS, где потерялась запись, около 1МБ. Период работы 8 месяцев. Корректировка введенной информации программно запрещена (только сторнирование). Программа на C55H, ШВС. Обнаружили расхождение в показаниях итогового отчета и кассовой ленты - ровно на 350 руб. Сумма небольшая, доложили в кассу, стали проверять. Весь товар на месте, все продажи по кассе и компьютеру за день совпадают. Позвонили. Проверяю TPSFIX - ошибок нет. Сверяю итоговые отчеты по месяцам. Обнаруживается отсутствие одной записи (шапки чека) по возврату товара в декабре.
До этого сбоев зафиксировано не было.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)

А откуда такая уверенность в том, что запись была удалена? Может она просто не была добавлена?
У тебя касса от считывателя работает или как? Если нет, то какие могут быть вопросы, просто не считали какой-нить товар и все.

Сергей.

Привет, Сергей!

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

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru

Написал: ClaList(2)

Hi.

Гораздо больше похоже на программно/человеческий фактор, чем на глюк драйвера БД. Возможно действительно в ситуации, когда сетка развалилась.
Чтобы при глюке драйвера так аккуратненько пропала запись, и tpsfix ничего не нашел... "Не верю" (с)

WBR, Nick Tsigouro mailto:nick@arsis.ru


(Добавление)

Гораздо больше похоже на программно/человеческий фактор, чем на глюк драйвера БД. Возможно действительно в ситуации, когда сетка развалилась.

Да, был обрыв сети. Странно, что пропала именно старая запись.

Чтобы при глюке драйвера так аккуратненько пропала запись, и tpsfix ничего не нашел... "Не верю" (с)

Я тоже так думал, пока своими глазами не увидел. Наверно, на таких задачах лучше юзать dat-формат, а tps - это в связке с терминалом. Слишком много глючного железа стало появляться.
У нас тут видеопрокатчики уже десяток винтов поменяли на двадцати закупленных машинах. Типа нарвались на бракованную партию. Или специально ломают...

С уважением,
Вячеслав Черников

"Скупой платит всю жизнь" (с)

WBR, Nick Tsigouro

Было такое и у меня.
После разборок выяснил причину:

- при добавлении новой записи стандартные шаблоны
сразу добавляют в файл "болванку" записи, в которой
инициализирована, обычно, только часть полей.
- при выходе из формы без сохранения эта запись просто
удаляется из файла. НО! При этом предполагается, что
за все время работы в форме указатель Primary-файла
стоял на этой новой записи.

Вот именно в последнем предположении и кроется возможная причина удаления чужой записи! Если по каким-либо причинам (ошибка программера или ошибка, к примеру, менеджера потоков) во время работы в форме произойдет перемещение указателя в Primary-файле на другую запись, то при выходе из формы без сохранения будет удалена именно ЭТА запись!

Я у себя, после обнаружения вышеперечисленного, сделал следующее:

1 ВНИМАТЕЛЬНО пересмотрел ИСХОДНЫЙ текст в присках потенциальных
мест изменения текущего указателя. А таких мест, кстати,
довольно много. Например:
- работаем в форме заголовка документа, оформляем новый документ
- для выбора клиента жмем на кнопку вызова каталога клиентов
- в этом каталоге открываем анкету клиента.
Если в анкете есть бровз по документам этого клиента, то
уже этого шага достаточно для того, что-бы сбить текущий
указатель в файле заголовков документов!
Поэтому для предотвращения вышесказанного просто "обрамил"
такой потенциально-проблемный код рамками SaveFile/RestoreFile.

2 Для исправления возможных "глюков" менеджера потоков сделал
небольшой глобальный шаблон, который во всех формах реализует
простенький алгоритм:
- ПОСЛЕ добавления "болванки" новой записи сохраняю ее позицию
в файле или Primary-ключе (если таковой есть) - POSITION().
- ПЕРЕД удалением записи (в случае выхода без сохранения)
сравниваю сохраненную позицию с текущей.
- если они совпадают - все нормально - можно продолжать
выполнение стандартного кода шаблона.
- если они не совпадают - ОШИБКА!!! - выдаю предупреждение
(что-бы операторы сообщили админу, а уже он - мне) и
делаю попытку считать запись по сохраненной позиции.
Если удалось - продолжаю выполнение стандартного кода
шаблона. Если нет - возможно какая-либо серьезная ошибка
с файлом - прерываю выполнение стандартного кода шаблона
и возвращаю оператора в форму. Естественно, в предупреждением
о возникшей ситуации и предложениями:
- повторить отмену чуть позже (возможно были временные
глюки с сетью)
- сообщить админу БД, который после проверок невозможности
нормального штатного решения данной ситуации просто
"снимает" прогу - таким образом предотвращая модификацию
"чужого" заголовка документа.

Кстати, было несколько срабатываний по вар.2.
Правда, всегда код сам исправлял возникший сбой, не доводя до вмешательства админа!

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)

Здравствуйте, Олег!
Чтения из проблемной таблицы после добавления в нее болванки новой записи в форме не вижу - уточнил все ветки, ходов немного, варианты короткие. Не гарантия, конечно...
Посмотрел, действительно, в ШВС проверка потери позиции записи при отказе от добавления отсутствует. Очень хорошая наводка, спасибо. Исправляю. Надо Вадиму сказать, если когда-нибудь под шестерку - есть смысл быть в базовом коде.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru

Написал: ClaList(2)

Угу. Старая фича. Но вообще-то она не только при удалении, но и при редактировании и добавлении всякими чудесами себя проявляет. Это трудно пропустить при тестировании-отладке.

WBR, Nick Tsigouro mailto:nick@arsis.ru

Да, проверку нужно ставить и на Update. Собственно, сейчас так и сделал. Как писал Олег, через небольшой глобальный extension. В более позднем проекте для фоновых расчетов и поисков (которые не видны из IDE) стал использовать алиасы. Но в описанном случае, похоже, дело не в этом. Помимо отсутствия кода, обащающегося к проблемной таблице в пределах потока, сохранилась дочерняя запись, связанная с потерянной соотношением MANY:1 и каскадным удалением. Связь через ID, не доступный для правки.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ry


(Добавление)

А уверен, что никто не хотел смухлевать/посмотреть/... и не зашел TopScan-ом? Понимаешь, совершенно непонятно, как могли остаться целыми ключи, если запись стала удаленной в результате сбоя. Как это оно все так аккуратненько получилось?

WBR, Nick Tsigouro
Написал: ClaList(2)

Nick,
TopScan не стоял, таблица закрыта паролем. Да и нет там шибко умных. Обрыв сети имел место и сигнал поступил посе него. Возможно, стечение обстоятельств. Ладно, понаблюдаем еще.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)