Hi All !

есть таблица

CREATE TABLE journal (
id int(10) NOT NULL auto_increment,
time timestamp(14) NOT NULL,
user varchar(32) NOT NULL default '',
session varchar(32) NOT NULL default '',
message varchar(240) NOT NULL default '',
connectLine varchar(240) NOT NULL default '',
page1 text NOT NULL,
page2 text NOT NULL,
page3 text NOT NULL,
PRIMARY KEY (id),
KEY user_time (user,time)
) TYPE=MyISAM;


при выполнении к ней запросов типа
select count(id) as jc from journal where user='picposter' and time >=20041019000000 and time <=20041019235959
select time,session from journal where user='picposter' and time>=20041019000000 and time<=20041019235959 order by time,session LIMIT 0,50

с сервера где установлен mysql, все замечательно, с удаленного - результата никакого

в my.cnf
.......................
[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer = 256M
table_cache = 256
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

net_buffer_length = 512K
max_allowed_packet = 16M
............................................

в таблице сейчас всего 17063 записей... с другими таблицами все замечательно,max_allowed_packet уведичивал до 64M - результат тот-же
mysql 4.0.21

вопрос - где что подкрутить ?

ничего не говорит, вообще ничего
ошибки - нет, данных то-же нет

точнее на select count(id) as jc from journal where user='picposter' and time >=20041019000000 and time <=20041019235959
результат - 0
на select time,session from journal where user='picposter' and time>=20041019000000 and time<=20041019235959 order by time,session LIMIT 0,50
ничего

реально записей по условию 90

ScareCrowсколько row's affected..?

0

maXmoпобовали версию обновлять?
ma X mo

версия последняя из 4.0

Хренну во первых max_allowed_packet тут неважен. Ведь в первом запросе ты получаешь просто count(*) - одно число, это должно работать при любом размере пакета.

Кроме того, при ошибке он бы тебе не вернул 0.


логично, я не сразу допер до этого

Хрентак что надо смотреть куда-то в другую сторону. Например , что ты коннектишся именно к той же базе, а не к (скажем) отладочной с полупустыми таблицами. Или например пользователь@'localhost' и пользователь@'%' имеют разные права на чтение этой таблицы. В общем что-то такое.

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

ХренЯ бы первым делом сделал бэкап с помощью mysqldump локально и с удаленного компьютера. И сравнил бы эти два файла с помощью diff. Тогда бы была пища для дальнейшей отладки.

посмотрю сейчас, но не совсем предстаавляю что это мне даст....

как мы к такой жизни пришли...
изначально был один сервак на котором крутилось www,mysql и прочая лабуда, решили mysql убрать на дрой сервер, новый. поинсталили Mysql сняли полный дамп со старого сервера mysqldump -u root -p -h 192.168.0.1 --add-drop-table --extended-insert --all-databases > dump.sql и затолкали его на новый
mysql -u root -p statistic < dump.sql. добавили грантов, переписали в совте адрес mysql сервера на новый и ... такое вот получили, причем только в одной базе и только с этой таблицей, причем insert'ы в нее идут нормально

maXmoверсия мускуля та же?
свежее

maXmoможет, скомпилилась криво.
вряд-ли, хотя все возможно, но это уже шаманство


maXmoПопробуй сохранить данные из таблицы, удали её, создай снова и заполни.
результат такой-же, да-же если данные в ней совсем прибить и подождать пока немного заполнится.... по сетке их не забрать

maXmoПопробуй на первом сервере восстановить базу из дампа , будет ли такой же глюк?
на первом сервере все нормально работает...

maXmoну проблема у вас тоже необычная. Да и линухи бывают разные...

у нас фря, а проблемма действително необычная

maXmoодинаковые оси на обоих серверах?
одинаковые

maXmoпопробуйте менять мускуль/ось/клиента.
начнем с мускула... похоже только это и остается

сменил сетевую карту и пересобрался - все пошло