mysql, problema con un campo

[}gu|do[z]{®©]

Non so come all'improvviso in un mio database locale mi son trovato una tabella che aveva una lettera accentata, con un punto interrogativo al posto della lettera accentata... e chiaramente non mi funzionava più...
[scemo pure io a metterci la lettera accentata ]

A quel punto mi sono accorto che alcune tabelle e/o alcuni campi avevano charset strani [collation utf8_swedish_ci]... a questo dovrei aver rimediato da phpmyadmin.. ma la tabella di cui sopra resta così e non posso farci nulla..

mysql 4.1, ma il databse in questione l'ho copiato dalla precedente installazione di mysql 4.0 trasferendo la directory "data"... all'inizio funzionava chiaramente....

che cacchio faccio?

[}gu|do[z]{®©]

ho risolto così:
ho fatto un dump del database, nel dump ho sostituito la lettera accentata con una non accentata, o reimportato la tabella in un altro database..

Com'era sclerata ancor anon l'ho capito.. però so che non userò più lettere accentate

[}gu|do[z]{®©]

ma perchè quando creo un nuovo database automaticamente mi mette swedish?

durante l'installazione ho lasciato il default [latin] e anche nel my.ini c'è quello... perchè da swedish?

[}gu|do[z]{®©]

ora oltretutto mi sono accorto che è diventato case sensitive nelle ricerche.. è indemoniato!

[piero.mac]

E' un problema di charset e non del collate. Il collation e' solo un algoritmo che serve ad ordinare le parole secondo un determinato alfabeto. Chi puo' fare casino e' mbstring che deve essere caricata come estensione. Il default collation nostro dovrebbe essere latin_general_ci/cs dove ci e cs stanno per case insensitive e case sensitive, che sostituiscono in pratica il vecchio BINARY che si poteva associare ai campi per renderli case sensitive di default.

Dato il charset che nel nostro caso in generale e' LATIN1, tutti i collation della serie LATIN1 sono validi. Si trattera' solo di ordinare delle lettere con accenti buffi in modo diverso o case sensitive oppure no.

Le cose si complicano dal momento che ci sono 4 o anche 5 possibilita' di avere charset diversi.....

character set client
character set connection
character set database
character set results
character set server
character set system

Chiaramente se i charset sono diversi occorre trasformare i dati che si gestiscono nel charset appropriato.

ma non finsce qui....

si possono avere anche COLLATION diverse....

collation connection
collation database
collation server

piu' quella specifica della colonna

Quindi in alcuni casi WHERE pippo like 'pallino' potrebbe portare un errore dal momento che il client, la connessione, e la tabella usano un diverso set di caratteri. Mentre un ordinamento potrebbe essere diverso da quello atteso.

E' un casino.... phpmyadmin si sta adeguando pian piano... offre gia' diversi tools per gestire i campi in modo diverso, per esempio far apparire in lettura la data nel formato italico, pur mantenendo nel db la data nel formato canonico....

Il problema pero' e' che lo fa lui, ma sei vai da php devi gestire tutto come prima. Puoi anche modificare il formato nelle variabili del server.... ma poi ti cicca tutte le date preesistenti.

mysql 4.1 e' un bel passo avanti, ma hanno fatto un casino bestiale.

Vedi le pwd, il trattamento dei caratteri e il puttanaio immenso del TIME ZONE.... per ora nessuno se ne accorge... ma se se ne dovesse avere bisogno .... altro che charset...

Dai una bella chiacchierata da sabato mattino... varrebbe veramente la spesa una pillola sul charset. Il problema e' capire come farla e come riuscire a spiegarla senza usare i termini del manuale che IMHO, non capisce nemmeno chi ha scritto.

[}gu|do[z]{®©]

grazie.. adesso è più chiaro

provo a smanettare.. che charset mi consigli di mettere?

attualmente ho sta roba qua

Variabile   	 Valore sessione   	 Valore globale 
character set client 	utf8 	latin1
character set connection 	latin1 	latin1
character set database 	latin1 	latin1
character set results 	utf8 	latin1
character set server 	latin1 	latin1
character set system 	utf8 	utf8
....
collation connection 	latin1_bin 	latin1_swedish_ci
collation database 	latin1_swedish_ci 	latin1_swedish_ci
collation server 	latin1_swedish_ci 	latin1_swedish_ci

le ricerche me le fa case sensitive
e non capisco quello swedish

[piero.mac]

devi vedere il collate della colonna. E' li che viene definito se deve essere o meno case sensitive. Valuta il suffisso _ci oppure _cs

come gia detto stanno per Case Sensitive oppure Insensitive.

Per la cronaca... su questo PC son messo cosi':

Variabile                sessione globale  
character set client      utf8    latin1  
character set connection  utf8    latin1  
character set database    latin1  latin1  
character set results     utf8    latin1  
character set server      latin1  latin1  
character set system      utf8    utf8  
 
collation connection  utf8_general_ci    latin1_swedish_ci  
collation database    latin1_swedish_ci  latin1_swedish_ci  
collation server      latin1_swedish_ci  latin1_swedish_ci

Le nuove tabelle le configuro come collate = latin1_general_ci e le colonne per default seguono. Comunque volendo si possono cambiare come ti serve.

Non ho assolutamente problemi. I problemi li avevo con le prime versioni 2.6 di phpmyadmin. Con la 2.6.2 ci sono altre cose che non vanno, pero' questa mi pare sistemata...

[piero.mac]

[supersaibal]Originariamente inviato da }gu|do[z]{®©
le ricerche me le fa case sensitive
e non capisco quello swedish [/supersaibal]

Lo swedish e' il default che gli sviluppatori hanno assegnato. Che fossero svedesi????

Non sono riuscito a cambiarlo a livello di variabile, ma solo a livello di database, tabella e colonne... ed ho messo appunto latin1_general_ci oppure latin1_general_cs se la colonna era varchar/char BINARY in precedenza.

[}gu|do[z]{®©]

ti ringrazio.. ci smanetto un po'...

[piero.mac]

[supersaibal]Originariamente inviato da }gu|do[z]{®©
ti ringrazio.. ci smanetto un po'...

[/supersaibal]

questo mi sa che sia il tuo case sensitive..

collation connection latin1_bin