Цитата(DENtt @ 20.2.2009, 17:36)
для начала начнем с того, где и как у тебя была реализована база на локальном сервере, а также обрати внимание на кодировки сервера локального и используемой версии базы. Второй вопрос в том, КАК ты переносишь базу и какими средствами. Если это просто дамп базы, то еще внимательнее гляди на кодировки и версии. Если СУБД phpmyadmin, то его версия тоже может иметь роль в таких вещах. Это я все к тому, что чаще всего такого рода ошибки именно из-за кодировок и различий синтаксиса различных версий субд. Не может ли быть такое, что например на локальном сервере у тебя была кодировка винды (1251), а сервере utf-8 или наоборот? вопщим чаще всего ошибки именно в непонимании двух сред. Поэтому можно попробовать использовать одну общую среду. Самым лучшим инструментом в рунете зовут Sypex Dumper... Сам только начну его щупать на днях, так что пока ничего сказать не могу опредленного. У меня сейчас подобная проблема.
сколько скриптов у тебя с ошибкой выполняют твою выборку? может есть смысл просто подправить скрипт и не трогать базу?
и третье... внимательно сравни конфиги своих серверов - локального и который на хосте, все ли там одинаково настроено?
ЗЫ: сейчас тоже парюсь над переносом базы одного форума, так что можем помочь друг другу, если че
стучи в аську и личку
=====
up
а если построже обозначить выборку значений? через условие например? ну и конечно нужны оба кода... и базы, и пхп... мож просто какой-то недочет, затрудняюсь с ходу сказать... а что вообще скрипт-то делать должен? =)
Не, с кодировками все в порядке, cp1251 и там, и там. Еще я думал, что это могут быть индексы, но сколько ни переиндексировал таблицы, ничего не изменилось. Сегодня нашел вот такую интересную информацию о различии между 4-й и 5-й версиями MySQL (на домашнем компе у меня 5-я версия, на новом сервере - 4-я):
Цитата
В предыдущих версиях MySQL оператор запятая (,) и JOIN имели одинаковый приоритет и выполнялись по порядку вхождения в запросе. Поэтому выражение
t1, t2 JOIN t3
интерпретировалось как
((t1, t2) JOIN t3)
В пятой версии оператор JOIN имеет более высокий приоритет, и описанное выше выражение интерпретируется иначе:
(t1, (t2 JOIN t3))
При этом может возникнуть ошибка:
Unknown column 't1.name' in 'on clause'
Для решения данной проблемы, необходимо изменить запрос, взяв в скобки имена таблиц после оператора FROM. Например, запрос:
SELECT count(*)FROM table1 t1, table2 t2
JOIN table3 t3 ON t1.id = t3.id WHERE …
надо заменить на:
SELECT count(*)FROM (table1 t1, table2 t2)
JOIN table3 t3 ON t1.id = t3.id WHERE …
Пока буду считать это рабочей версией, хотя и непонятно, относится ли это к нашей проблеме или нет. Приду домой - попробую скобочки расставить - мож, поможет...
Скриптов, на которых вылезает эта ошибка, немного, но все важные - генерация, автосостав, отправка состава на матч, назначение судей на матч. В принципе, исправить-то можно, но это получится один, а то и несколько дополнительных селектов в каждом скрипте.
Вот, например, назначение судей на матчи. Нужно выбрать тех судей, которые еще не назначены ни на один из сегодняшних матчей, для этого делаем left join таблицы, содержащей календарь матчей, по условию, что такой судья назначен на матч, а потом оставляем только те записи, для которых это условие не выполнено:
select rf.id from referees rf
left join match_schedule msc
join tournament_schedule tsc on msc.tour_sch = tsc.id
and tsc.day = {$game_day} on rf.id = msc.referee, teams tm_h, teams tm_g
where rf.town != tm_h.town and tm_h.id = {$hosts} and
rf.town != tm_g.town and tm_g.id = {$guests} and
msc.id is null and rf.nation = tm_h.country
Конкретно на этом селекте не пробовал выкинуть выделенное курсивом, но думаю, что если его выкинуть, то работать будет нормально. А в таком виде не работает.
будет что-то типа этого?
