MySQL 4.1.13

Re: MySQL 4.1.13

KRoN73, ты не прав.

Re: MySQL 4.1.13

> Однако, не вижу никаких оснований по которым это там не должно работать. Если файл явно указать, конечно

Кульно. Продолжай в том же духе.

Re: MySQL 4.1.13

Нахрен надо? Хостеры всё равно ещё долго будут ставить 4.0.xx (и это правильно)

Re: MySQL 4.1.13

> Хостеры всё равно ещё долго будут ставить 4.0.xx

Но не вечно же...

atrus (23.07.2005 2:48:06)

Re: MySQL 4.1.13

>Но не вечно же...

смена аутентификации в C клиенте без договорённсти с теми кто использует это (например в php) - неуважение ко свему сообществу ...

Re: MySQL 4.1.13

да и 4.0.xx стабильные

Re: MySQL 4.1.13

Работалось на восьмерке и, кажется, на девятке.

NLS_LANG (например, AMERICAN_AMERICA.UTF8) в клиентский енвайронмент и едем подключаться. Ну и на серверной стороне наш ораклоид чего-то настраивал, понятное дело.

AlexM (23.07.2005 9:44:20)

Re: MySQL 4.1.13

А, ну, на всякий случай. Клиент был использовал для работы с базой OTL, который непосредственно на оракловых клиентских либах лежит. Во всяких PHP могут существовать и другие механизмы, я не в курсе.

AlexM (23.07.2005 9:49:50)

Re: MySQL 4.1.13

> AMERICAN_AMERICA.UTF8

Нет, это не интересно. Мерикосам и ASCII за глаза хватит. Даже если
чего-то не так работает с utf-8, очень трудно будет заметить ;)

Re: MySQL 4.1.13

> Ну и на серверной стороне наш ораклоид чего-то настраивал, понятное дело

create database .... character set XXXX ... :-)

no-dashi (23.07.2005 16:22:20)

Re: MySQL 4.1.13

Ну, извиняй, дорогой товарищ, тот конкретный код не был предназначен для работы конкретно на просторах 1/ гхм, сколько там сейчас осталось? седьмой? части суши.

Но сортировка работала. В том числе, и для русских. Впрочем, когда в качестве кодировки стояла CP1251 - тоже работало. Так что, дело в руках кодописателей, а не в кривости технологий.

AlexM (24.07.2005 14:56:06)

Re: MySQL 4.1.13

Наверняка. Но, знаете, кесарю - кесарево. У нас с ним договор был, мы не раздаем кредиты, а он не торгует семечками. Может быть, и зря, как показала жизнь...

AlexM (24.07.2005 14:57:12)

Re: MySQL 4.1.13

"UTF давно есть. Проблема в координации сервер-клиент."

Критики поведения MySQL 4.1 с множественными кодировками - а как вы предложили бы чтобы все это работало ?

В 4.0 все тривиально у сервера только одна кодировка у всех таблиц. в MySQL 4.1 может быть разная кодировка не только у баз данных и таблиц но даже и отдельных столбцов. Соответственно просто вести обмен с клиентом в кодировке X не получается.

Проблемы лезут от бойцовского подхода - заменю сервер и все и видимо даже не чтения Upgrade Notes. Для кликетов есть прикрасная команда SET NAMES - SET NAMES win1251 и сервер будет воспринимать данные этого клиента в win1251 как и отдавать результаты.

Re: MySQL 4.1.13

> "смена аутентификации в C клиенте без договорённсти с теми кто использует это (например в php) - неуважение ко свему сообществу ..."

1) MySQL сервер можно настроить (--old-passwords) на использование только старой аутентификации если есть приложения с использованием старых либ.

2) PHP отлично компилится с использованием 4.1 клиентских либ. То что некоторые тормозные вендоры вроде RedHat продолжали поставлять софт скомпилированный с MySQL 3.23 или 4.0 не вина MySQL.

Re: MySQL 4.1.13

Потрясающая дисскуссия о кодировках!

А "Changes in release 4.1.13" по ссылке слабо было почитать?

-Added mysql_set_character_set() C API function for setting the default character set of the current connection.(Bug #8317)