|
|
|
| Здравствуйте!
Подскажите, пожалуйста, с чем может быть связана ошибка счетчика посещений:
Произошла исключительная ситуация (ExceptionMySQL) при обращении к СУБД MySQL.
Duplicate entry '2012-01-01' for key 2
INSERT INTO powercounter_arch_clients_month VALUES(NULL,
'2012-01-01',
563,
80,
2,
282,
11,
99,
40,
940,
18,
5,
88)
Ошибка в файле .../dmn/system_powercounter/utils.client.php в строке 214. | |
|
|
|
|
|
|
|
для: vialis
(02.02.2012 в 20:02)
| | Какая версия счетчика используется?
Удаление записи 2012-01-01 из powercounter_arch_clients_month не приводит к возобновлению функциональности? | |
|
|
|
|
|
|
|
для: cheops
(03.02.2012 в 13:50)
| | Версия счетчика 4.2.0.
После удаления записи обновляю страницу счетчика сначала появляется ошибка "Произошла исключительная ситуация (ExceptionMySQL) при обращении к СУБД MySQL.
Duplicate entry '2012-01-01' for key 2
INSERT INTO powercounter_arch_hits_month VALUES(NULL,
'2012-01-01',
1112, 963, 2557, 2358)
Ошибка в файле .../dmn/system_powercounter/utils.hits.php в строке 173."
Затем при повторном обновлении возвращается прежняя ошибка и в powercounter_arch_clients_month вновь появляется эта же запись 2012-01-01, но уже с id_client = 2, при повторном удалении опять же только поменялся id_client = 3. | |
|
|
|
|
|
|
|
для: vialis
(03.02.2012 в 15:03)
| | 1) Когда началась проблема в феврале (или в январе архивация не проводилась и архивация идет за два месяца январь-февраль)?
2) Насколько велика ваша база данных?
3) Можете ли вы её выслать нам (нет ли там секретных данных), чтобы мы могли воспроизвести ситуацию и создать патч? | |
|
|
|
|
|
|
|
для: cheops
(03.02.2012 в 15:15)
| | Счетчик был запущен с 15 января, выдавать ошибку стал в ночь с 1 на 2 февраля.
База небольшая - 341Кб, на какой адрес можно отправить? | |
|
|
|
|
|
|
|
для: vialis
(03.02.2012 в 15:53)
| | Отлично, если не сложно вышлите на igor@softtime.ru. | |
|
|
|
|
|
|
|
для: vialis
(03.02.2012 в 15:53)
| | Хм... пока не удалось воспроизвести, у меня счетчик сразу заработал на ваших данных, без попыток повторно архивировать данные за январь. Последний раз когда такое наблюдалось дело было в разных часовых поясах в PHP и MySQL. Если не сложно посмотрите совпадает ли время в PHP и в MySQL (счетчик к этому чувствителен)? | |
|
|
|
|
|
|
|
для: cheops
(03.02.2012 в 16:52)
| | Все в порядке таймзоны совпадают. Есть ли какое-либо временное решение? Или следует переустановить счетчик? | |
|
|
|
|
|
|
|
для: vialis
(03.02.2012 в 17:58)
| | Вероятно переустановка счетчика временно решит проблему, но до начала марта, когда возможо ситуация повторится. Можно поступить так или если хотите, можем попытаться докопаться до причин, почему происходит именно так, но потребуется редактировать код, внося в него отладочные записи, чтобы можно было локализовать участок, который вызывает сбой. | |
|
|
|
|
|
|
|
для: cheops
(03.02.2012 в 18:07)
| | Да Вы правы лучше, конечно произвести полную отладку и докопаться до причин, так как постоянная переустановка проблемы не решает и сама система сбора статистики теряет смысл в таком случее. | |
|
|
|
|
|
|
|
для: vialis
(03.02.2012 в 18:13)
| | Если вам не сложно, то, пожалуйста, найдите файл dmn/system_powercounter/utils.client.php. В этом файле три функции, сбой происходит в последней, которая несет ответственность за архивацию месячных данных
function archive_clients_month($tbl_arch_clients, $tbl_arch_clients_month)
| Перед условиемпожалуйста разместите следующий код
echo "last_day = $last_day<br />";
echo "begin_day = $begin_day<br />";
echo "month = $month<br />";
exit();
| и сообщите что он возвращает? | |
|
|
|
|
|
|
|
для: cheops
(03.02.2012 в 18:25)
| | Прошу прощения за задержку с ответом - после размещения кода возвращает следующие значения:
"last_day = 1328378402
begin_day = 1328029200
month = 1" | |
|
|
|
|
|
|
|
для: vialis
(06.02.2012 в 07:24)
| | Все-таки что-то со временем, не хватает трех часов (если это так, то проблему мы, конечно решим довольно быстро). Чтобы проверить, давайте заменим предыдущий код следующим, что он возвращает?
echo date("Y-m-d H:i:s")."<br />";
$query = "SELECT NOW() FROM DUAL";
echo query_result($query)."<br />";
exit();
|
| |
|
|
|
|
|
|
|
для: cheops
(06.02.2012 в 11:28)
| | Действительно было упущение - разница составила 1 час:
2012-02-06 14:22:07
2012-02-06 15:22:07 | |
|
|
|
|
|
|
|
для: vialis
(06.02.2012 в 12:34)
| | Нужно, чтобы у них время было одинаково, какое правильно? В PHP или в MySQL? | |
|
|
|
|
|
|
|
для: cheops
(06.02.2012 в 12:56)
| | Правильное время, соответствующее нашему региону, указано во второй строке - я так понимаю это MySQL. | |
|
|
|
|
|
|
|
для: vialis
(06.02.2012 в 13:21)
| | Тогда в конфигурационный файл config.php нужно добавить строку, подобрав нужный часовой пояс, чтобы значения в MySQL и в PHP у вас сравнялись (если есть доступ к php.ini это можно сделать для всего сервера при помощи директивы date.timezone в секции [Date])
@date_default_timezone_set("Europe/Moscow");
|
| |
|
|
|
|
|
|
|
для: cheops
(06.02.2012 в 14:37)
| | К сожалению, прямого доступа к этому файлу нет - придется договариваться через провайдера. Подскажите, а если для PHP в настоящее время установлен регион "Asia/Novosibirsk" (что по идее должно соответствовать нашему часовому поясу однако - судя по тестам, проведенным с Вами выдает значение меньше на час почему-то), а в phpmyadmin для MySQL выводит параметр SYSTEM - нельзя ли произвести изменения именно в phphmyadmin? | |
|
|
|
|
|
|
|
для: vialis
(06.02.2012 в 17:52)
| | Вы можете без php.ini изменить часовой пояс, просто эта настройка будет производиться всякий раз при выполнении PHP-скрипта. Так как в каждом файле вызывается config.php, лучше сделать это через него, для этого, добавьте в него строку
<?php
@date_default_timezone_set("Asia/Novosibirsk");
?>
|
PS Только обязательно поэксперементируйте, так как из-за отмены летнего времени все российские пояса сместились, компьютерщики наоборот зимнее время переводят. Поэтому если у вас библиотека ответственная за часовой пояс PHP не обновилась (а судя по всему это и является причиной разницы), то возможно вам придется указать не свой часовой пояс, а соседний... мы например вместо Москвы сейчас Баку указываем (возможно и вам придется что-то в этом духе сделать). | |
|
|
|
|
|
|
|
для: cheops
(06.02.2012 в 18:08)
| | Все заработало! Насчет сдвига поясов - верно подмечено - нужно было заменить на соседний часовой пояс. Огромное Вам спасибо за помощь!! | |
|
|
|