When I try to export a MySQL 4.026 database with SQLyog 5.1 beta I get the attached error message.

A file is generated reading:




Now .. neither 'SET NAMES' or the utf8 character set is valid with MySQL 4.0.


This export error occurs with various characters sets for the server.
Obviously, as SQLyog has no charset conversion library of its own, it depends on the MySQL server to do the job.
And MySQL 4.0 cannot utf8_encode. I guess that is why nothing is returned.

I think the encoding (ANSI-localisation or UFT8) should be user configurable with MySQL 4.1 ++.
With this it is also not possible either to export from MySQL 5.x and import into MySQL 4.0 with other characters than the ASCII-subset.
People use that a lot! (local 5.0, webhost 4.0).

And I do think you should discuss such changes in public!
This change would be a very big and very bad change to a lot of people if they were not aware!
Please remember that the world is much bigger than Bangalore. MUCH MORE information on what is going on, please!! DAILY blogging!!!

There are no such problems with 5.02. But of course it will only work with the subset of characters supported by the localization.
SQLyog 5.1 also works with MySQL 5.x because here the server knows the utf8 encoding.

Clarification



The use of term ANSI here is confusing

I would rather say: let user choose between 'save as stored in database' or 'encode and save as utf8'.

Starting from BETA 5, SQLyog will provide you an option in SCHEDULED BATCH EXPORT WIZARD to specify whether you want to export the data in UF8 or not. This is required when a user wants to export data from v4.1 and above tries to import in a MySQL version < 4.1.

When you export from MySQL version less than 4.1, this option does not have any meaning as you cannot export in utf8 with that version.

SCHEDULED BATCH EXPORT WIZARD

That is a new name isn't it?
And what about the 'ordinary' export tool then? 'As is' with MySQL 3-4.0 and uft8 with MySQL 4.1++?


That was my point too!

And I suppose that the <charset> specified wil be used for


and only that? Just like SQLyog beta4 does?

Now that would actually allow for syncing data between databases having different charset with MySQL 4.1++ when specifying <utf8>, as the SJA would use utf8 internally and the server would convert charset when storing data as described in defaults or columnn-definitions.

Am I right?

I meant Powertools -> Scheduled Backups

Ordinary export will not have this option. It will export with utf8 for versions > 4.1 and normal when versions < 4.1. We dont plan to add any new features in the normal export. All the new improvements will be done in Powertools -> Scheduled Backup.



Not in BETA 4. We have still not finalised the design regarding this as of now.