Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: PowerCounter: ошибка Duplicate entry
 
 автор: vialis   (02.02.2012 в 20:02)   письмо автору
 
 

Здравствуйте!

Подскажите, пожалуйста, с чем может быть связана ошибка счетчика посещений:
Произошла исключительная ситуация (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.

  Ответить  
 
 автор: cheops   (03.02.2012 в 13:50)   письмо автору
 
   для: vialis   (02.02.2012 в 20:02)
 

Какая версия счетчика используется?

Удаление записи 2012-01-01 из powercounter_arch_clients_month не приводит к возобновлению функциональности?

  Ответить  
 
 автор: vialis   (03.02.2012 в 15:03)   письмо автору
 
   для: 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.

  Ответить  
 
 автор: cheops   (03.02.2012 в 15:15)   письмо автору
 
   для: vialis   (03.02.2012 в 15:03)
 

1) Когда началась проблема в феврале (или в январе архивация не проводилась и архивация идет за два месяца январь-февраль)?
2) Насколько велика ваша база данных?
3) Можете ли вы её выслать нам (нет ли там секретных данных), чтобы мы могли воспроизвести ситуацию и создать патч?

  Ответить  
 
 автор: vialis   (03.02.2012 в 15:53)   письмо автору
 
   для: cheops   (03.02.2012 в 15:15)
 

Счетчик был запущен с 15 января, выдавать ошибку стал в ночь с 1 на 2 февраля.
База небольшая - 341Кб, на какой адрес можно отправить?

  Ответить  
 
 автор: cheops   (03.02.2012 в 15:57)   письмо автору
 
   для: vialis   (03.02.2012 в 15:53)
 

Отлично, если не сложно вышлите на igor@softtime.ru.

  Ответить  
 
 автор: cheops   (03.02.2012 в 16:52)   письмо автору
 
   для: vialis   (03.02.2012 в 15:53)
 

Хм... пока не удалось воспроизвести, у меня счетчик сразу заработал на ваших данных, без попыток повторно архивировать данные за январь. Последний раз когда такое наблюдалось дело было в разных часовых поясах в PHP и MySQL. Если не сложно посмотрите совпадает ли время в PHP и в MySQL (счетчик к этому чувствителен)?

  Ответить  
 
 автор: vialis   (03.02.2012 в 17:58)   письмо автору
 
   для: cheops   (03.02.2012 в 16:52)
 

Все в порядке таймзоны совпадают. Есть ли какое-либо временное решение? Или следует переустановить счетчик?

  Ответить  
 
 автор: cheops   (03.02.2012 в 18:07)   письмо автору
 
   для: vialis   (03.02.2012 в 17:58)
 

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

  Ответить  
 
 автор: vialis   (03.02.2012 в 18:13)   письмо автору
 
   для: cheops   (03.02.2012 в 18:07)
 

Да Вы правы лучше, конечно произвести полную отладку и докопаться до причин, так как постоянная переустановка проблемы не решает и сама система сбора статистики теряет смысл в таком случее.

  Ответить  
 
 автор: cheops   (03.02.2012 в 18:25)   письмо автору
 
   для: vialis   (03.02.2012 в 18:13)
 

Если вам не сложно, то, пожалуйста, найдите файл dmn/system_powercounter/utils.client.php. В этом файле три функции, сбой происходит в последней, которая несет ответственность за архивацию месячных данных
  function archive_clients_month($tbl_arch_clients, $tbl_arch_clients_month)
Перед условием
    if ($month > 0)
пожалуйста разместите следующий код
    echo "last_day = $last_day<br />";
    echo "begin_day = $begin_day<br />";
    echo "month = $month<br />";
    exit();
и сообщите что он возвращает?

  Ответить  
 
 автор: vialis   (06.02.2012 в 07:24)   письмо автору
 
   для: cheops   (03.02.2012 в 18:25)
 

Прошу прощения за задержку с ответом - после размещения кода возвращает следующие значения:
"last_day = 1328378402
begin_day = 1328029200
month = 1"

  Ответить  
 
 автор: cheops   (06.02.2012 в 11:28)   письмо автору
 
   для: 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();

  Ответить  
 
 автор: vialis   (06.02.2012 в 12:34)   письмо автору
 
   для: cheops   (06.02.2012 в 11:28)
 

Действительно было упущение - разница составила 1 час:
2012-02-06 14:22:07
2012-02-06 15:22:07

  Ответить  
 
 автор: cheops   (06.02.2012 в 12:56)   письмо автору
 
   для: vialis   (06.02.2012 в 12:34)
 

Нужно, чтобы у них время было одинаково, какое правильно? В PHP или в MySQL?

  Ответить  
 
 автор: vialis   (06.02.2012 в 13:21)   письмо автору
 
   для: cheops   (06.02.2012 в 12:56)
 

Правильное время, соответствующее нашему региону, указано во второй строке - я так понимаю это MySQL.

  Ответить  
 
 автор: cheops   (06.02.2012 в 14:37)   письмо автору
 
   для: vialis   (06.02.2012 в 13:21)
 

Тогда в конфигурационный файл config.php нужно добавить строку, подобрав нужный часовой пояс, чтобы значения в MySQL и в PHP у вас сравнялись (если есть доступ к php.ini это можно сделать для всего сервера при помощи директивы date.timezone в секции [Date])
  @date_default_timezone_set("Europe/Moscow");

  Ответить  
 
 автор: vialis   (06.02.2012 в 17:52)   письмо автору
 
   для: cheops   (06.02.2012 в 14:37)
 

К сожалению, прямого доступа к этому файлу нет - придется договариваться через провайдера. Подскажите, а если для PHP в настоящее время установлен регион "Asia/Novosibirsk" (что по идее должно соответствовать нашему часовому поясу однако - судя по тестам, проведенным с Вами выдает значение меньше на час почему-то), а в phpmyadmin для MySQL выводит параметр SYSTEM - нельзя ли произвести изменения именно в phphmyadmin?

  Ответить  
 
 автор: cheops   (06.02.2012 в 18:08)   письмо автору
 
   для: vialis   (06.02.2012 в 17:52)
 

Вы можете без php.ini изменить часовой пояс, просто эта настройка будет производиться всякий раз при выполнении PHP-скрипта. Так как в каждом файле вызывается config.php, лучше сделать это через него, для этого, добавьте в него строку
<?php
 
@date_default_timezone_set("Asia/Novosibirsk");
?>

PS Только обязательно поэксперементируйте, так как из-за отмены летнего времени все российские пояса сместились, компьютерщики наоборот зимнее время переводят. Поэтому если у вас библиотека ответственная за часовой пояс PHP не обновилась (а судя по всему это и является причиной разницы), то возможно вам придется указать не свой часовой пояс, а соседний... мы например вместо Москвы сейчас Баку указываем (возможно и вам придется что-то в этом духе сделать).

  Ответить  
 
 автор: vialis   (06.02.2012 в 18:31)   письмо автору
 
   для: cheops   (06.02.2012 в 18:08)
 

Все заработало! Насчет сдвига поясов - верно подмечено - нужно было заменить на соседний часовой пояс. Огромное Вам спасибо за помощь!!

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования