Apr 16

На сайте http://www.only-poker.ru/ я разместил рекламу Google-Adsense, но недавно узнал что на сайтах по азартным играм нельзя размещать адсенс. Решил убрать эту рекламу, и убрал, но она все равно присутствовала на сайте если смотреть из дома. Пробовал менять заголовки опять же никаких изменений в браузере.

Читать далее »

Теги: ,

Jun 17

Буквально 3 дня назад имел счастье поразбираться (полазить по кодам) - такое случается редко, и после подобных разборок довольно хорошо поднимается экспириенс. А что еще нужно программисту кроме регулярного поднятия уровня опытности!?

Описание диспозиции

Есть форма, в этой форме есть поле для ввода даты/времени, для удобства ввода прикручена к этому полю JavaScript библиотека JSCalendar (симпотичный и удобный выпадающий календарик)

По сабмиту дата/время вставляется в таблицу в виде UnixTime, для конвертации в формат UnixTime использую следующую функцию

function format_to_unixtime($t)
{
   list($date, $time) = split(' ', $t);list($day, $mon, $year) = split("/", $date);
   list($hour, $min) = split(':', $time);    return mktime($hour, $min, 0, $mon, $day, $year);
}

Для работы с базой данных MySQL использую библиотеку Дмитрия Котерова DBSimple.

Проблема

Проблема состояла в том, что когда просматривал список записей, даты отличалась от тех которые вводил на 6 часов.

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

Следующий тестовый пример показал что дело в функции mysql FROM_UNIXTIME

<?php
include_once('conf.php');
include_once('lib/dbsimple/mysql.php');
//Подключаемся в MySQL
$db = DbSimple_Generic::connect("mysql://".$mysql_user.":".$mysql_passwd."@".$mysql_host."/".$mysql_db);
// Устанавливаем обработчик ошибок MySQL.
$db->setErrorHandler('databaseErrorHandler');
$db->setIdentPrefix($mysql_table_prefix);
 
$dt = '18/06/2008 10:10';
 
$db->query("insert into test (dt) values (?)", format_to_unixtime($dt));
 
echo $dt."<br>";
echo format_to_unixtime($dt)."<br>";
 
$recs = $db->select("select id, dt, FROM_UNIXTIME(dt, '%d/%m/%Y  %H:%i') ddt from test");
print_r($recs);
 
function format_to_unixtime($t)
{
list($date, $time) = split(' ', $t);
list($day, $mon, $year) = split("/", $date);
list($hour, $min) = split(':', $time);</strong>
 
return mktime($hour, $min, 0, $mon, $day, $year);
}
?>

18/06/2008 10:10
1213783800
Array
(
[id] => 1
[dt] => 1213783800
[ddt] => 18/06/2008 16:10
)

А вот что написано на странице http://dev.mysql.com/doc/refman/6.0/en/date-and-time-functions.html

FROM_UNIXTIME() functions return values in the connection’s current time zone, which is available as the value of the time_zone system variable.

Вывод: читать документацию надо чаще.

Теги: , ,

Apr 15

Значит ситуация такая, есть у меня на работе замечательная программы 1С-архив. Использует она в качестве СУБД MSSQL. Собственно я это все хозяйство не сопровождаю, но есть на нашем внутреннем сайте отчеты по исполнению заданий, данные этих отчетов берутся из MSSQL.

Отчеты имеют параметрами:
Автора задания;
Исполнителя;
две даты;
Исполнение: Просрочено/Вовремя/Все;
Состояние: В работе/Выполнено/Все.

Все прекрасно работало!

Звонит значит мне админ 1С-архива, через много месяцев работы отчетов и просит зайти к нему.

А дело оказалось в том, что при обращении к хранимой процедуре с опр. параметрами выдавалось 3 записи в браузере (PHP, Apache, Solaris). А с теми же параметрами в программе MS SQL Server Management Studio (Windows XP)выдавалось четыре записи.

Реальный такой полтергейст.

Для чистоты эксперимента распечатал переменную SQL в браузере, в MS SQL Server Management Studio также 4 записи, а в браузере 3.

Ппц.

Посмотрели логи сервера, запросы попадающие серваку идентичны. Много было высказано в адрес Microsoft…

Решение

Причина была в том, что сравнение дат давало сбой. В SQL даты передавались строково и преобразовывались CONVERT(SMALLDATETIME, @FromDate) где @FromDate - строка

А нужно было

CONVERT(SMALLDATETIME, @FromDate, 104)

Применение данной функции было в нескольких местах, и только в одном месте допущена опечатка.

Зы. Процедуру писал не йааа :-)

Теги: , ,

Jan 20

Дело было так:

Звонит пользователь и жалуется что сортировка вывода данных из MySQL неправильная, т.е. не по алфавиту.

Полез в php скрипты и вытащил запрос который так криво работал,  примечательно что в order by стояло поле по которому нужно было сортировать по алфавиту, вобщем вытащил sql запрос и запустил его в утилите SQLyog. Запрос выдал данные но сортировка по указанному в order by  полю не была адекватной.

Полез в свойства таблицы все тем же SQLyog, командой alter_table, смотрю, а на Collation установлено latin1_swedish_ci - вот почему не по русски сортировка! Меняю ее на cp1251_general_ci, жму кнопочку Alter_Table, радуюсь что быстро отделался. Но …

Не тут то было данные в поле испортились, каждая русская буква превратилась в знак вопроса, замена свойства Collation положения не исправило.

#$%^&*

Итого, т.к. данных для восстановления не было пришлось восстанавливать данные руками - 2 дня 3 человека, хотя нет вру не 3 человека, остальные 4 человека работали от 3 часа - 8 часов.

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

ЗЫ. чето дневник у меня получается о глюках MySQL

Теги: ,

Dec 08

Проблема:

Есть два веб. ресурса: Один под Solaris_10, PHP_4, MySQL5. А второй WindowsXP, PHP5, MySQL4. Понадобилось мне из Windows обратиться в базу MySQL5 (которая на Solaris). Создал пользователя, чтобы обращаться с любого хоста, а не только в localhost, написал небольшой запрос и о чудо - все русские буквы распечатались знаками вопросов. $%^&* на соляре то все работает и уже давно (

Перерыл весь интернет в поисках рецепта, а там советуют делать правки в my.cnf прописать кодировку или в php скрипте сразу после конекта тоже обозначить кодировку cp1251. Ничего мне из этих советов не помогло.

А помогло вот что. На виндовс запустил из far-a стандартного консольного клиента mysql, но приконектился к серверу который на солярисе, сделал запрос, и что вижу … конечно кракозябры, но не вопросики, т.е. все в порядке!!! буквы windows-1251 кодировки в консоли выглядят кракозябрами. Пишу команду SET NAMES ‘cp1251′ как было написано на многочисленных сайтах найденных гуглом, делаю опять запрос, оппа, теперь вопросики заместо русских букв.

Решение:

Короче говоря в начале работы с mysql в скрипте php поставить след. строку

mysql_query(’SET NAMES “latin1″‘);

после этого все заработало, осталось только недоумение, почему latin1 правильно отображает русские буквы.

P.S. Вообще в mysql если посмотреть variables много переменных в которых храниться кодировка, конечно каждая переменная отвечает за что то свое, но видимо их многочисленность влияет на путаницу в этом вопросе.

Теги: , ,

Nov 09

Сегодня в FireFox обнаружил что при обновлении через Xajax обновленная таблица выглядит так как будто там перепутаны открывающие/закрывающие теги (td, tr).

Сразу скажу что в IE6 этого не происходит.

С помощью Web Developer Toolbar смотрю (View Generated Source), и что вижу:

1) Тег form из первой ячейки закрыт, хотя я его не закрывал

2) Тег TD тоже закрыт, причем до содержимого ячейки, после содержимого естественно стоит </td> поставленное мною

Каждая строка таблицы содержит форму, вот так схематически выглядит строка, если таблицу получаю не через ajax

<tr>
   <td><form ...>1</td>
   <td>2</td>
   <td><input ...>3</td>
   <td></form>x</td>
</tr>

А вот так через xajax

<tr>
   <td><form ...></form>1</td>
   <td>2</td>
   <td><input ...>3</td>
   <td></td>x</td>
</tr>

Решение как такое победить пока не найдено …

Теги: ,

Oct 23

Ошибка наверное все таки не php, а моя собственная, хотя кто его знает может так и должно обрабатываться …

Итак как я наступил на эти грабли: в массиве $_REQUEST лежит переменная operator в переменной значение 0, в операторе if сравниваю значение этой переменной с нулем

if ($_REQUEST["operator"] != 0)
   echo "Not ok";
else
   echo "Ok";

И вижу на выводе “Not ok”. Я точно знаю что в переменной $_REQUEST["operator"] лежит ноль, более того я вижу это распечатав массив $_REQUEST, командой print_r($_REQUEST);

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

Пока товарищь шел, за эти 5 секунд я поставил ноль в кавычки, и оппа все заработало, и товарищь выпалил что нужно поставить !== (восклицательный знак и два равно), хм всю жизнь сравнивал == или !=, полез в документацию разбираться с темой.

В документации написано:
$a !== $b Неидентичность True, если $а не равно $b, или они разного типа

Товариш был не прав, но его указание из этой темы.

Копаем дальше, функцией gettype($_REQUEST["operator"]) выясняю что у меня из формы нуль приходит строкового типа, а нуль без кавычек естественно числовой тип. Хм. ну и что PHP слабо типизированный язык программирования, когда нужно приведение типов должно сработать автоматом, но у меня в скрипте в IF этого не произошло :-(

Итого: Или это у меня такая версия php, или учить php лучше надо было, блин и такие грабли после 3,5 лет программирования на php, стыд и позор.

Теги: , ,

Oct 17

 

Собственно ошибку обнаружил выполняя один проект.

Суть: При запросе из таблицы взято значение из поля float (это была цена), нужно было запросить из этой же таблицы все записи с такой же ценой.

Проблема: Ни одной записи по запросу MySQL не вернул. Что довольно таки странно т.к. должна быть хотя бы одна запись из которой эту цифру взяли.

Решение:
По запросу mysql float problem Гугл выдал первой в списке
http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html
Где написано о данной проблеме, шо дескать зависит от архитектуры компьютера, т.е. процессор виноват

Потом указано как победить данный казус, т.е. применяя функцию round
и …
перед этим написано
Warning
Never use this method in your applications. It is not an example of a trustworthy method!

и как быть после таких заявлений.

Я конечно в запросе функцию применил, все заработало, но …
… осадок то остался.

Теги: , ,