Export Error

Hello,

i have a problem with heidiSQL. My MySQL Server has a CHARSET=latin1.

I created a table "test" with 2 fields. 1'st Field is only a "id" field (Int, Autoincrement) und the second field is "text" (varchar 255 chars max.)

The Problem is to export this table, when text includes a "

Achso f

I will analyze that issue asap.

Oh I just see that this is not a bug, but a feature - really! I tested it for example with a string "

On my local Server re-import doesnt work. Local Version of mysql is 4.0.16-nt with latin1 charset.

The Server where i try to export the data has version: 4.1.11 -Debian

The string "

OK, you're absolutey right. I tested the above INSERT-statement with various server-versions:

4.0.27: "You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '0x962068616C6C6F)'"

4.1.22: Runs fine

5.0.18: Runs fine

5.1.12: Runs fine

So we have a version issue here. We will try to fix that for lower versions.

That's odd. No MySQL-doc says in which version they introduced these "introducers" like _latin1. Even the 4.0.20 manual say that they're supported although we definitely found out the opposite: http://modular.fas.harvard.edu/docs/debian-packages/mysql-doc/manual_Language_Structure.html

Just having to do some further googling...

I'm getting a similar problem with the Greek Tonos character (΄).

It made Heidisql hang when I tried to do an export from one table to another.

HeidiSql: v3.0 Revision 572

Please see here for my bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1708421&group_id=164593&atid=832347

Hi@all

i remotely run a MySQL 4.0x (Linux) and a local 5.1 (WAMP with XAMPP). Both(!) dont understand 0x...

Is there any option to set that 0x-feature off?

Hi@all

i remotely run a MySQL 4.0x (Linux) and a local 5.1 (WAMP with XAMPP). Both(!) dont understand 0x...

Is there any option to set that 0x-feature off?

Jeah the best way is to add a button or something, to set this 0x-feature off.

Better way is when Heidi-SQL scans the version of mysql by itself and then it turns off features that not supported by the servers.

Better way is when Heidi-SQL scans the version of mysql by itself and then it turns off features that not supported by the servers.

Exactly what we do by taking care of what the user selects in the dropdown "Target compatibility". But we do not make any differences with these introducers currently. As described above we need to know since which mysql-version exactly support for introducers exists. I guess it's 4.1 .

i remotely run a MySQL 4.0x (Linux) and a local 5.1 (WAMP with XAMPP). Both(!) dont understand 0x...

Is there any option to set that 0x-feature off?

That's interesting. 'mysql --help|more' doesn't reveal the existence of any buttons to turn off this individual SQL feature..

Is this a custom compile of MySQL Server, or is it a binary downloaded from www.mysql.com ?

[...] we need to know since which mysql-version exactly support for introducers exists. I guess it's 4.1.

Sounds good, stripping introducers for target versions less than 4.1 should make import work on pre-4.1 servers. Not sure what to do about the case that "esc" presents, but it could always be labeled a freak occurrence ;-)..

Stripping the introducer will work fine as long as files are imported and exported on the same box. Horrible things (silent corruption) will start happening if you take the file with you and import it on a Windows box which uses a different ANSI code page. So if the introducer is stripped, it would be very nice to additionally present a warning when a character with the 8th bit set is found in non-Unicode files. It could say something like "Loaded ANSI file (no Unicode BOM). File contains extended characters and will be imported using the local code page, which might not be the code page used for exporting the file. Please double check that the import went ok when you're done." Or something like that?

I have the same problem with characters čČ

I'm happy to report that after creating a donor database (with charset
utf8) I was able to successfully export the tables containing the offending
characters using 3.1 RC1 (rev 1064)

Woohoo!

Thanks HeidiSql