Mysql mi yade "я"...

Mysql mi yade bukva 'я' pri set ili enum pole. Nyakakva ideq kak da se spravya s tozi bag na Mysql?

Професионалистите може би ще измислят нещо по-добро..аз само мога да гадя...
Та значи 'я' е с ASCII код 255 (което може би се ползва от Mysql?) и като се има предвид, че поддръжката на UTF-8 я няма все още мога да ти препоръчам следното...
- Ако не използваш целият спектър от букви (ASCII кодове) изплзвай друга буква ако е възможно.. например 'ю' е с ASCII код 254... като сравнително лесно можеш да промениш заявката така, че тази буква да се ползва вместо 'я'.
- Далеч по-смисленото решение (според мен) е да изчакаш малко версия 4.1 която отдавна е анонсирана.. и всички с затаен дъх чакаме бинарита-та...та там 'обещават' Unicode поддръжка...
Може би някой друг ще даде по-добро решение или обяснение за мистериозната буква 'я'

Кажи със какво вмъкваш и четеш данните? С "я" обикновено там някъде възниква проблем.


При ENUM "имената" на възможните стойности се пазят само в дефиницията на таблицата а в редовете се пази индекса като число (при SET е подобно). Тъй, че я дай един дъмп на структурата да го видим.

salle.online.bg/sig

Problema ne e v nachina po-koito vmakvam dannite ili v strukturata. Yavno e bug v MySql-a. Maj ste go laja s po-gornia mi ukazan nachin:-(

Не!

Ако е бъг в MySQL дай ми начин да го повторя за да го поправим.

Пусни ми едно SHOW CREATE TABLE на твоята таблица и след това какво се получава при INSERT, UPDATE е SELECT.

salle.online.bg/sig

Отговарям ти аз защото и аз направих тест и установих същото, но може би в действителност, по-скоро съм бил прав за липсата на unicode support. Сега ще обясня.. Тестовте ги правих със phpMyAdmin, което най-вероятно е направил колегата..само че буквата 'я' във IE е доста по-ралична от същата буква в командният промпт (XP) и mysql.
Ако искаш да го симулираш пробвай със обикновено създаване на таблица.. но не със SQL стейтмънт а директно с phpMyAdmin.
Когато създадох през mysql таблицата буквата 'я' стана на 'y'... с няколко думи ето тази таблица работи перфектно през mysql:
CREATE TABLE demo (
ID INT NOT NULL auto_increment PRIMARY KEY,
COL1 ENUM('0','1','ÿ') default '0',
COL2 varchar(20) NOT NULL default '',
) TYPE=MyISAM;
и както виждате 'y'-ка въобще не е 'я' въпреки че го копирах от текстовият редактор... но проблемите със ANSI,Unicode,UTF-8 и т.н. са добре известни...
Та..когато се ползва "дугото" 'я' проблеми със работата се решават... така че може би спасението е UTF-8... а в конкретният случай мога да кажа на колегата да си напише create стейтманите на ръка и да ги пусне например през конзолата на mysql (mysql -uuser -p database < sql_file.sql)
и предполагам че ако редактора с който е писал SQL-a е "свестен"..mysql ще го разбере правилно...
Иначе дъпа на таблицата показва '' (празен символ..при това 2-броя) когато се използва ето това "я" :-)
Btw salle имаш ли source-a на 4.1 в "нормален" вид така че да се компилира с VC 6?

Хмм още нещо странно &#255; не съм го писал аз... т.е форум-а на дир.бг го преправи... дори и едно Php не могат да направят да работи правилно :-))
Майтапя се защото вината за преобразуването или изчезването на 'я'-то да е по-грешка на phpMyAdmin.. т.е при създаването на таблицата практически Mysql може да е получил некоректен стейтмънт.. това може да го потвърди евентуално пича с въпроса, дали е ползвал phpMyAdmin..както направих аз :-)

phpMyAdmin-а работи по подразбиране (ако не го смениш) с en-iso-8859-1 и в същност сичко там нагоре излиза в такива символи &#255; за програмки дето не работат в тоз енкодинг. той браузера след това си ги вижда нормално щото е в същият енкодинг (mysql - я вижда обаче така странно щото не е в тоз енкодинг), както при copy-paste се в страница, която е в windows-1251 (дира) се конвертира в &#255; (нищо, че пак е браузер, но в друг енкодинг) и затова при нас излиза така, още при теб е конвентирана - може да видиш, че няколко пъти иначе си писал 'я'

(а бе никак професионално не го обясних, ама поне требе се разбере надявам се)

Значи първият ми отговор на yanko беше точно с идеята, че най-често проблема с "я" то е при въвеждане/извеждане.

Имам някакъв смътен спомен за оплаквания от PHPMyAdmin, но тъй като това е продукт с който нямам нищо общо (дори и като потребител не никога не съм го харисвал) затова и не го коментирам.

Това е другата част от въпроса. PHPMyAdmin няма нищо общо с MySQL AB и не бих се заел да решавам проблеми с него.

За съжаление по стечение на обстаятелствата в момента никакви проби не мога да направя ... използвам RedHat 8.0 а в него всичко е UNICODE и нямам време да инсталирам локал за CP1251 пък и вероятно ще настане боза.

yanko

такъв проблем досега никой не е съобщавал, но бъгове винаги има така, че моля те разкажи точно кога и как ще се проявява та до го почистим. По една случайност бъговете в MySQL са ми основна задачка та мога да ти обещая, че няма да потъне без отговор само щото е за cp1251

salle.online.bg/sig

при мен поне резултата беше такъв
ако пиша през mySqlAdmin - ядне буквата Я
ако пиша през конзолата - не я яде...

[линк]

Sorry za reakciata srestu MySql. Greshkata e v PHPMyadmin.
Blagodarya za pomostta.

що се извиняваш?

не знаеш - питаш....кво от това че си питал?

[линк]

Проблемът е ясен ... за съжаление не ми си вярва да се оправи в скоро време защото ще се наложат сериозни промени тук-там.

Най-веселото в цялата работа е страничния ефект с коъто се сблъсках.

Няма никакъв проблем с UTF-8 стойности в ENUM и SET при което се оказва, че в такива колонки могат да има UTF-8 вкл. и в 3.23 независимо от пълната липса на каквато и да е поддръжка. Т.е. такава колонка става независима от кодовата таблица ....

Развитието на историята - на [линк]

salle.online.bg/sig

В PHPMyadmin може и да има проблеми с кирилицата, но аз го тествах с конозлния клиент и проблем маистина има.

Не знам дали е същия като твоя.

Освен това не съм съгласен, че реакцията ти беше Срещу! MySQL. Напротив. Когато намериш грешка и я кажеш има шанс да се поправи. Тъй, че това само помага на MySQL. "Срещу" би било ако махнеш с ръка и си затраеш

salle.online.bg/sig

Ako tryabva da sam chesten, MySQL mi dopada kato baza danni. To bez greshki ne moje. A inache kombinaciata PHP/MySQL pozvolyava predavaneto na informaciata na bazova cena blizka do nulata, tai che da jiveee PHP/MySQL makar i s nyakoq i druga greshka otvreme-navreme.

eval(a)

Еee хубавото е че при MySQL 4.11 този бъг го няма...за това и не видях бъга в конзолата.. тъй или инач бъдещето е в 4x, 5x..тъй че на кой му пука

Забравих да спомена..че ако ще документират бъга..не е лошо да се опише, че бъга несъществува при 4.x(поне не и на 4.11) до колкото си спомням формата на таблиците в 4.x бе променен...?

Аз щото го пробвах в 4.0 и 4.1 и си е все още така.

В 4.1 нещата са значително по-сложни заради поддръжката на кодови таблици на всички нива.

Не знам откъде си спомняш, че "формата на таблиците в 4.x бе променен..."

При всички положения обаче разликата между 4.1 и 4.0 е значително по-голяма отколкото между 3.23 и 4.0

salle.online.bg/sig

Останал съм с такова впечатление... може би да е било на нещо друго..например bin лог-а... на истина не се сещам...
Относно бъга много зависи с какъв encoding и респективно с каква OS си го тествал... например 'я' е с код 255 в смисъла на енкодинга който ползвах(в PhpMyAdmin).. докато в DOS промта може би не е със стойност 255 (друг енкодинг) или просто phpmyadmin-a не работи много добре с кирилицата...
Аз лично действах както си дал примера за възпроизвеждане на бъга.. в mysql написах create стейтмънт-а и след това лист-нах резултата със създадената таблица...screen shot можеш да видиш на следният адрес: [линк]