Странный глюк при закрытии смены с доп. отчетами.

[Alexander]

На втором. Снимал отчеты по кассирам за 03.05, 02.05, 01.05 - снимаются.

Сейчас посмотрел БД транзакций поподробнее за 1 мая - есть странный проскок во внутренних номерах транзакций 59859, 59860, 59891, 59892.
Как будто PostgreSQL сначала занял номер транзакции, а потом (вероятно из-за перезагрузки) удалил запись.

Что-нибудь на тему ошибок Postgres можно попробовать посмотреть в /tmp/dancy/postgres_log/tranactions[дата].log

[Бродяга_Джон]

Появилось время смотаться до магазина.
В общем дела так:
через терминал и перенаправление вывода в файл "reshka > ......" не хотит, файл пустой, вероятно потому что процесс прибивать приходиться по kill, иначе он так и висит не реагируя.

по кассирам отчет так и не снимает там до сих пор на этом РМ (зависает, и 30 минут тогда ждал, пофиг), на втором РМ - нормально, но они его руками перед закрытием смены делают.

tmp/dancy/postgres_log/tranactions[дата].log

вроде смотрел, ничего там нет такого подозрительного

Сейчас посмотрел БД транзакций поподробнее за 1 мая - есть странный проскок во внутренних номерах транзакций 59859, 59860, 59891, 59892.
Как будто PostgreSQL сначала занял номер транзакции, а потом (вероятно из-за перезагрузки) удалил запись

так и даты транзакций с номерами 59891 уже за 2 мая, как раз когда смогли смену закрыть за 1 мая на том РМ

[Alexander]

Может быть попробовать сделать бэкап БД Transaction, а затем восстановить её из бэкапа? (С нашего диска это можно сделать через меню icewm и при этом база на самом деле пересоздается с нуля). У меня после восстановления из присланного ранее бэкапа отчеты снимаются без проблем.

[Бродяга_Джон]

Попробую

[Бродяга_Джон]

пи-пи-пи-пи-пи (вырезано цензурой)

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

Что могу сказать про общие моменты, кол-во транзакций в обеих базах сейчас за 80 тысяч, отчет продаж выгружаеться вручную через пункт меню "Сервис", галочка об пометке транзакций выгруженными не устанавливалась ни разу.

PS
на 4 мая в базе где первой проявился глюк количество транзакций (по номерам в файле report.txt) было:
61419;04.05.2011;18:14:00

во второй, когда на тот момент она точно снимала отчёт по кассрам:
55368;04.05.2011;18:11:00

[Alexander]

80 тысяч для PostgreSQL совсем незначительное количество. Версия PostgreSQL, кстати, какая?
Постараюсь завтра сделать сборку с подробнейшим протоколом снятия отчета по кассирам, чтобы отловить момент "подвисания".

[Бродяга_Джон]

80 тысяч для PostgreSQL совсем незначительное количество. Версия PostgreSQL, кстати, какая?
Постараюсь завтра сделать сборку с подробнейшим протоколом снятия отчета по кассирам, чтобы отловить момент "подвисания".

Да по количеству записей согласен - это семечки для него.
Но вот как-то так получается, возможно это вариант совокупного использования, или варианта модели использоваия.

Ставилось с комплекта из ISO записаного на болванку.
Версия 8.3.4 (в PSQL по команде "SELECT version();")

[Бродяга_Джон]

Сейчас посидел, полистал исходники из миниобраза 8 патча.

Print_ReportCashiers упоминается только в libhwsrv.so
Но 4 раза, 2 в сочетании с ATOL и 2 в сочетании с MERKURII

Может дело в сервере оборудования?
Или в его одной версии (32 или 64), учитывая процессор установилась скорее всего 64 битная версия.

[Alexander]

Если смотреть исходники, то начинать надо с /src/Interfaces/ServiceLib/reportform.ui.h - функция int reportForm::PrintCashierReport()

[Бродяга_Джон]

Погляжу, просто там различие в знаке подчёркивания.
PrintCashier и Print_Cashier