Просмотр полной версии : Вопрос по mySQL
Народ кто знает в чем причина вывода вместо русских букв знаков вопроса???
Через phpmyadmin в базе он пишет по русски, а при чтения из базы в браузер знаки вопроса. Помогите пожалуста
В кодировках дело. База и страница должны юзать одинаковую кодировку.
Попробуй поставить и там и там кои-8.
В кодировках дело. База и страница должны юзать одинаковую кодировку.
Попробуй поставить и там и там кои-8.
Вот это добрый совет!
Срочно.
Не могу понять почему не заполняютя таблицы в mysql путём LOAD DATA
Сам запрос:
mysql> LOAD DATA INFILE "data.sql" INTO TABLE zakazchik FIELDS TERMINATED BY ',' ;
Структура таблицы zakazchik:
id_zakazchika numeric(4) primary key
familia char(20) not null
name char(20) not null
Структура файла
1,Verin,Alex
2,Kozlov,Mizail
...etc
Выдаёт с звуковым сопрождение динамика компа вот с таким сообщением
' for column 'id_zakazchika' at row 2 value: '
Не могу понять в чём дело. Пробывал и без TERMINATED BY ',' когда по дефаулту табуляция считается разделителем между колонками, переход на новую строку-разделитель между сстроками таблицы. Выдаёт тоже самое. Как я понял в id_zakazchika записывется 2 значения что не длжно быть. Хы как испрвить хз. Помогите если занете.
Строки как делятся? \n или \r\n (или \n\r)
Может добавить LINES TERMINATED BY '\r\n';
Строки как делятся? \n или \r\n (или \n\r)
Может добавить LINES TERMINATED BY '\r\n';
К тому времени допедрил но всё равно спасиб. Хы вот токо мучает почему во всех книгах сказано что по дефаулту должно всё пахать а на самаом деле приходится указывать ограничители.
Типа если файл простой структуры типа
Фамилия ИМЯ Отчесвто
Фамилия2 ИМЯ2 Отчесвто2
Хы и запрос
LOAD DATA INFILE "data.sql" INTO TABLE zakazchik
не пашет
во всех книгах сказано что по дефаулту должно всё пахать
Лучше указывать все явно, чтоб потом гемора не обрести. Стандарты меняются, а запросы остаются. =)
Лучше указывать все явно, чтоб потом гемора не обрести. Стандарты меняются, а запросы остаются. =)
+1. сам попадал в такую запару. при переезде на новые версии сервера mysql, параметры по умолчанию становились другими и нередко приходилось наблюдать на экране не совсем то, что хотелось
есть некая проблема, которую мой мозг отказывается понимать.
есть база, в которую методом insert пишется информация, допустим, названия файлов из директории. (не путать с содержимым файлов) так вот, раньше на старом сервере всё было ок. на новом появился какой-то трабл. есть поле id , которое автоматом увеличивается при добавлении записи т.е auto_increment так вот. теперь при добавлении данных идентификаторы идут не по порядку, а хаотично. 1.2.3.4.5 так было, а теперь при добавлении ещё 5 записей будет вот так 1.2.3.4.5.10.9.8.7.6 понимаю, что в принципе насрать, всё решается order by id desc or asc но для меня это проблема. есть ли варианты решения, очень буду благодарен.
А auto_increment в этой ячейке не убрать ?
А auto_increment в этой ячейке не убрать ?
хм, убрать можно, но тогда прийдется самому вычислять значения id. либо хранить его последнее значение, либо делать на всю базу count. База около 50т. строк, дальше больше =)
возможное решение. при удалении записей из таблицы, без её оптимизации ловим эти самые глюки. если после удаления оптимизировать её, то всё в порядке. нумерация производится, как надо. странно всё это, раньше таких глюков не замечал, таблицы могли быть не оптимизнуты месяцами и прекрасно работали без проблем.
Очень странно, т.к. When you insert a value of NULL (recommended) or 0 into an AUTO_INCREMENT column, the column is set to value+1, where value is the largest value for the column currently in the table. AUTO_INCREMENT sequences begin with 1.
Как выход можно попробовать
SELECT @next_id:=MAX(`id`+1) FROM `my_table`;
INSERT INTO `my_table` (`id`,`text`) VALUES (@next_id, 'блаблабла');
хм, а у меня постоянно такая фигня после удаления каких-либо строчек из таблицы, странно, что раньше у тебя этого не было. Хотя может я раньше просто не замечала, что этого не было, т к таблицы огромные были и черт его знает что там и в каком порядке. А чем это тебе так сильно мешает?
огласите версии/платформы?
линух, версия майскл - 5.0.26. До этого какая версия была не помню, но так же и не помню были ли такие проблемы на ней, и там винда стояла.
линух, версия майскл - 5.0.26...были ли такие проблемы на ней
Я сомневаюсь, что auto_increment обязана давать индексы последовательно. Ее задача давать уникальные индексы. Возможно, в новых версиях есть какая-нибудь оптимизация, поэтому назначает их таким хитрым алгоритмом, хз.
ps: linux/mysql 4.1.
она ведет себя на самом деле так: было пять строчек 1 2 3 4 5, удалили первые две: 3 4 5, потом добавили еще две и в итоге получается 6 7 3 4 5, если еще строчка добавляется, то получается 6 7 3 4 5 8, т е, грубо говоря, новые строчки встают на место удаленных, а если удаленных нет, то в самый конец, не думаю, что это глюк :)
Кошмар какой!!! Это же RDBMS, что значит "новые строчки встают на место удаленных"?! О порядке строк говорить бессмысленно, если нет определяющего порядок выражения. Никто и никогда не гарантировал вам порядок, откуда ему быть?
Вообще, Кодекс прав. В СУБД "порядок следования строк и столбцов может быть произвольным". =) Не обязана она это делать.
Мне все же непонятно, в чем сложность использования "order by" и почему это проблема?
Вообще, Кодекс прав. В СУБД "порядок следования строк и столбцов может быть произвольным". =) Не обязана она это делать.
Мне все же непонятно, в чем сложность использования "order by" и почему это проблема?
А вот ты - не прав. Между RDBMS и СУБД есть существенная разница. Букву R видишь?
А вот ты - не прав. Между RDBMS и СУБД есть существенная разница. Букву R видишь?
Ок. СУРБД.
Кошмар какой!!! Это же RDBMS, что значит "новые строчки встают на место удаленных"?! О порядке строк говорить бессмысленно, если нет определяющего порядок выражения. Никто и никогда не гарантировал вам порядок, откуда ему быть?
что ты паникуешь? мне этот порядок и не нужен был никогда, наоборот мы все узнать пытаемся зачем он нужен был аларме, а на счет "новые строчки встают на место удаленных" - просто небольшое наблюдение, произведенное во время тестирования одной штуки, я могу быть не права ибо не было целью отследить как база себя ведет
что ты паникуешь? мне этот порядок и не нужен был никогда, наоборот мы все узнать пытаемся зачем он нужен был аларме, а на счет "новые строчки встают на место удаленных" - просто небольшое наблюдение, произведенное во время тестирования одной штуки, я могу быть не права ибо не было целью отследить как база себя ведет
Я не паникую, а в свое манере говорю, что
О порядке строк говорить бессмысленно
И наблюдения здесь пофигу. А если интересна ситуация с алярмой - спросите у него, помечен ли автоинкрементный столбец как PK. Возможно это прояснит дело :)
помечен ли автоинкрементный столбец как PK.
Если речь идет о PRIMARY KEY, то это роли не играет. Пусть он будет просто KEY или UNIQUE KEY, получим те же яйца в профиль.
Если речь идет о PRIMARY KEY, то это роли не играет. Пусть он будет просто KEY или UNIQUE KEY, получим те же яйца в профиль.
К чему ты это сказал - непонятно. Лично я пытаюсь понять, индексируется ли у него этот столбец. В случае если индексируется - то препятствий сделать ORDER нет никаких. В случае если нет - то почему нет?
К чему ты это сказал - непонятно.
К тому, что столбец с auto_increment в mysql всегда индексируется. Да и ORDER BY замечательно работает и на безиндексных столбцах. Правда, медленнее.
К тому, что столбец с auto_increment в mysql всегда индексируется. Да и ORDER BY замечательно работает и на безиндексных столбцах. Правда, медленнее.
Да, верно, индексируются.
Вопрос, я так понимаю, именно в скорости.
vBulletin® v3.8.12 by vBS, Copyright ©2000-2024, vBulletin Solutions, Inc. Перевод: zCarot