Да, забавно))
Ты PMA юзаешь?)

Co0L угу, привык) он в основном нужен для создания таблиц и проверки запросов)

neo_rage
А я как Navicat увидел так PMA больше не признаю ни в каком виде))

Co0L Я несколько таких клиентов в свое время юзал. Сейчас же нет смысла - я в базе провожу минимум времени. Да и не все хостеры дают внешний коннект к мускулу.

neo_rage
http тоннель рулит, он идет с ним в комплекте))
несколько таких клиентов
Такого как навикат больше не встречал) Всякие EMS - ерунда) Поэтому и крепко сижу на нем)

мда ну и страшилки
+1 к Навикатикам

Co0L Ну нет особой необходимости) Но учту. Была у меня раньше любимая немецкая прога, но ее поддержку прекратили...
Aristey хехе) так страшилка не из-за PMA, а из-за какого-то косяка в мускуле)

Была у меня раньше любимая немецкая прога, но ее поддержку прекратили...
Не MySQL Front ли?) Если он, то это наиболее похожий на Navicat менеджер баз)) Собственно, до того как узнали о Навикате, пользовались именно им))

Co0L во, точно) он самый) я уж за давностью лет забыл - последний раз фиг знает когда пользовался)))

я за последние две недели из-за БД тоже чуть крышу не потерял.

1.
Таблица содержит два поля decimal(12,0). Есть ещё некое поле-признак. Пишу select if(priznak = 1, POLE, POLE2) as POLE from tablitsa. И получаю часть данных в виде 99999999999, которых там вообще нет. Сижу, туплю. Оказалось, мускуль при подобном выражении автоматом стал преобразовывать результат в int(11) и, если поле не помещалось, нес вот такую ересь.

2.
Есть таблица с большим количеством записей. Одно из полей varchar(12). Все выборки типа select * from tablitsa where POLE = '123123123' работают хорошо. Но стоит один раз выполнить запрос типа select * from tablitsa where POLE in('123123123', '321321321', '2132132123') и трындец. Смотришь глазами — есть значение. Делаешь селект — ни одной записи. Вообще никак. Удаляешь-создаешь-заполняешь таблицу заново — работает. Выполняешь запрос с in — молча перестают работать выборки. Оказалось, работать снова без пересоздания будет либо если через LIKE, либо после явного преобразования в запросе поля с помощью binary.

3.
Вложеный запрос типа select * from tablitsa1 where POLE not in (select POLE from tablitsa2) исключить из таблицы 1 все записи, которые есть в таблице 2 перестает выдавать адекватный результат если во второй таблице несколько тысяч уникальных записей. Единственный вариант который пока хотькак-то работает — проверять скриптом в цикле по результатам запроса select POLE from tablitsa2 наличие записей через select count(*) from tablitsa1 where POLE = POLEizTABLITSY2.

Wizard of the North угу, с таким всегда морочишься и думаешь, где ты дурак...

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

Lotion преобразовал(вероятно) предыдущий программист, так что я даже не сразу сообразил ))))))

neo_rage
))

SELECT * FROM table ORDER BY cost спасло бы отца русской демократии

Таз Особенно если это форма поиска, и тебе надо написать минимальную и максимальную цены под соответствующими полями ввода. О, да. Просто кривую выдачу я заметил в процессе отладки сортировки.

Кстати, в описанной ситуации ордер так же работал бы некорректно.