Лазил в базу на таблицу payment_transactions - платежи были сформированны.
Подскажите, в чем может быть проблема?
Сборка 11452 от 14.01.2010 не формирует отчет по платежам
Сборка 11452 от 14.01.2010 не формирует отчет по платежам
Установили новую версию админки. Перестал формироваться отчет по платежам конкретного пользователя. Хоть основной отчет по платежам формируется.
Лазил в базу на таблицу payment_transactions - платежи были сформированны.
Подскажите, в чем может быть проблема?
Лазил в базу на таблицу payment_transactions - платежи были сформированны.
Подскажите, в чем может быть проблема?
Начинаю по-немногу разбираться во всем этом. Может быть мои предположения двинут ход рассуждений.
На мой взгляд, данная ошибка чем-то связана с архивацией таблиц discount_transactions_iptraffic_all(хранение списаний по трафику) и discount_transactions_all(хранение денежных списаний).
Первым делом глянул в таблицу archives(где хранятся архивы по этим двум таблицам). У меня их накопилось 6 штук по предыдушим месяцам. Последний архив от 2010.01. Архивация ежемесячная.
Вторым делом иду в админку и делаю отчет по платежам за несколько лет. Верхняя граница периода отчета - текущий день. И замечаю такую закономерность: отчет формируется по тем платежам, дата которых превышает дату последнего архива.
На этом пока расследование приостановлено, буду копать дальше.
Надеюсь и на вашу помошь в мозговом штурме
На мой взгляд, данная ошибка чем-то связана с архивацией таблиц discount_transactions_iptraffic_all(хранение списаний по трафику) и discount_transactions_all(хранение денежных списаний).
Первым делом глянул в таблицу archives(где хранятся архивы по этим двум таблицам). У меня их накопилось 6 штук по предыдушим месяцам. Последний архив от 2010.01. Архивация ежемесячная.
Вторым делом иду в админку и делаю отчет по платежам за несколько лет. Верхняя граница периода отчета - текущий день. И замечаю такую закономерность: отчет формируется по тем платежам, дата которых превышает дату последнего архива.
На этом пока расследование приостановлено, буду копать дальше.
Надеюсь и на вашу помошь в мозговом штурме
Ну очевидно архивирование таблиц сделали неверно.
Прочитайте внимательно инструкцию , может быть вы упустили такие моменты:
- архивировать нужно ВСЕ таблицы, для которых предусмотрено архивирование (а не только dscount_transactions_*)
- даты должны быть синхронными
- у синхронных таблиц должны быть одинаковые archive_id
Прочитайте внимательно инструкцию , может быть вы упустили такие моменты:
- архивировать нужно ВСЕ таблицы, для которых предусмотрено архивирование (а не только dscount_transactions_*)
- даты должны быть синхронными
- у синхронных таблиц должны быть одинаковые archive_id
Могу вас заверить в том, что архивирование было сделано правильно. заархивированны были следующие таблицы:dwemer писал(а):Ну очевидно архивирование таблиц сделали неверно.
Прочитайте внимательно инструкцию , может быть вы упустили такие моменты:
- архивировать нужно ВСЕ таблицы, для которых предусмотрено архивирование (а не только dscount_transactions_*)
- даты должны быть синхронными
- у синхронных таблиц должны быть одинаковые archive_id
1 UTM5H.payment_transactions_201002
2 UTM5H.discount_transactions_all_201002
3 UTM5H.discount_transactions_iptraffic_all_201002
НО, большое НО!
так как ранее архивирование таблиц выполнялось только для 2-х таблиц UTM5H.discount_transactions_iptraffic_all и UTM5H.discount_transactions_all значение поля archive_id для этих двух таблиц с каждой архивацией увеличивалось на 1.
Другим языком, если ранее архивацию таблиц изначально сделать для 2-х таблиц, а потом сделать для 3-х таблиц, то появится явное различие значений поля archive_id. Потому, что счетчик для новой таблицы начнется с 1, а не с того значения, которые имеют ранее отархивированные таблицы UTM5H.discount_transactions_all и UTM5H.discount_transactions_iptraffic_all
Логика работы архивации таблиц, ИМХО, расчитана по назначению нумерации archive_id неверна