Hi,
I've got Uniform Server 3.2a. My browser - when I am accessing dynamics pages using Uniserver - still switches to latin1 but on the hosted server the exactly same application runs as I want, i.e. cp1250 is in use.

Can you give me an advice how to overcome the problem? I am getting mad!!!

I am affraid that MySQL server under Uniserver is not properly set.
For each case here are some MySQL Server variables>>>

Variable Session value Global value
...
character set client latin1 latin1
character set connection cp1250 latin1
character set database latin1 latin1
character set results latin1 latin1
character set server latin1 latin1
character set system utf8 utf8
...
collation connection cp1250_czech_cs latin1_swedish_ci
collation database latin1_swedish_ci latin1_swedish_ci
collation server latin1_swedish_ci latin1_swedish_ci
.............
Thanks in an advance
MarHaj

I'm confused, the problem with the char set on your browser, did you say that its from MySQL or from the server itself.

I think it's an Apache-related problem, pushing out forced Latin-1 output.

Check whether in the file httpd.conf -- in the [path-to-Uniserver]\diskw\usr\local\Apache2\conf\ directory -- the AddDefaultCharset still is set to the default value of ISO-8859-1 (which is Latin-1)

Change it to CP1250 and see if that solves your problem; if it does, it's because Apache's encoding overrides the MySQL server output (makes sense, as Apache wraps everything up from the back-end and serves the end product)

I think my problem is the same as in the thread

http://forum.uniformserver.com/index.php?showtopic=151

which started on July. And is still opend...

MarHaj

I've got it.

1. changing Apache default charset as stated in the post above.
2. adding 2 lines of the code to the file \user\local\mysql\bin\my_small.cnf

namely
...
character-set-server = cp1250
collation-server = cp1250_general_ci
# Uncomment the following if you are NOT using BDB tables
...

After restarting MySQL system variables are:
Variable Session value Global value
character set client latin1 cp1250
character set connection cp1250 cp1250
character set database cp1250 cp1250
character set results latin1 cp1250
character set server cp1250 cp1250
character set system utf8 utf8
collation connection cp1250_czech_cs cp1250_general_ci
collation database cp1250_general_ci cp1250_general_ci
collation server cp1250_general_ci cp1250_general_ci
..
that's just I wanted.

The rest of charsets with latin1 are of no interest - they are for the purpose of the communication berween console and PHP and can be set in PHP.

I think it may works with another charsets as well.

Thanks ALL for their assisstance!
MarHaj

Ok

I will ask the community what they want the default charset to be for Apache and MySQL.

Good idea indeed!
... and include into install documentations the short descrition of "how to change the default prefs". It will be of great help for us, newbies ...

MarHaj

Probably will be added to the Wiki.

In fact, you can do it yourself, its simple.

http://wiki.uniformserver.com/Charset_Changing

Put it there.

Yes, it's even better idea. So I will try it ...
MarHaj

Thanks, i see it

Hi, could your perhaps give me some hits as to how to display German charcters properly. I use Mambo, and in my local (Mambo Stand Alone Server, MSAS) installation, everythings works just fine. I like the UniServer, so I want to abondon MSAS. I created a new installation on UniServer 3.3. The german charcters are correctly shown in the content but not in the headings and menu-text.

I have tried everythings, but I guess I just do not get it. The MySQL daatabase of the MSAS did not allow defining the charset, so I assume it was latin1. Now, I created one DB on the UniServer with latin1general, lat1german1ci, lat1german2ci, lat1swedishci, lat1binary, none worked.

In addition I have got this DB error:
DB function failed with error number 1054
Unknown column 'c.access' in 'on clause' SQL=SELECT c.*, g.name AS groupname, cc.name, u.name AS editor, f.content_id AS frontpage, s.title AS section_name, v.name AS author FROM mos_content AS c, mos_categories AS cc, mos_sections AS s LEFT JOIN mos_groups AS g ON g.id = c.access LEFT JOIN mos_users AS u ON u.id = c.checked_out LEFT JOIN mos_users AS v ON v.id = c.created_by LEFT JOIN mos_content_frontpage AS f ON f.content_id = c.id WHERE c.state >= 0 AND c.catid=cc.id AND cc.section=s.id AND s.scope='content' ORDER BY s.title, c.catid, cc.ordering, cc.title, c.ordering LIMIT 0,10

Any help is much appreciated,

--doc

Hi! I am having similar problems but with German charcters. In a live -> UniServer migration the installation survives in that the German characters are properly shown. Now on the live MySQL.4.0.25 server I assume the default charset is latin1. This is what I set in the phpMyAdmin for the MySQL database into which I imported the live sites, exported database.

I also went into the \user\local\mysql\bin\my_small.cnf and assed the two lines you suggested as

character-set-server = latin1
collation-server = latin1

I rerun the server. The server comes up, MySQL runs by phpMyAdmin stalls (actually does not come up).

Resetting to the originals with the \user\local\mysql\bin\my_small.cnf cures this problem.

However, becasue of the lower version number of the live MySQL relative to that in the UniServer3.3, I have to export the DB with MySQL4.0 Compatibility ON. The German charcters are NOT shown correctly. This effectively makes local development for the live site impossible.

Thanks for your help,

--doc

Don't loose your heart!
I believe we'll overcome all obstacles you have mentioned.
I am using Mambo too and, I must admit, it took me a month to make all things play together. Including mambo - it was the last straw - not mentioned in this thread - file includes/database.php should be tuned to your language too.
And I have exactly the same problems with data migration from local to live site (mySQL 5 and mySQL 4). And again, resolved it without mentioning it in this thread.

So, let us go together step by step. Do you agree?

a) So, your live site works correctly, doesn't it?
And you have problems with local installation OR with transferring data from local to live? (I didn't exactly catch where the problem was exactly?)

Possibility is that the next version will have a lower MySQL version and the rest will be made a plugin... but again, *time* Definately not on my side... haven't watch TV for 3/4+ weeks now since school start... School > Work > Home > Homework > Sleep, or School > Home > Sleep > Homework > Sleep > Talk to my girl for the amount of time i can, if i can.