Export Error
| User, date | Message |
|---|---|
|
Written by CoS
6 years ago Category: Import/Export 4 posts since Thu, 12 Apr 07 |
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 "–"! Please note: The Problem char is "–" (the long one) not "-". ID TEXT 1 hello – you If i try to export this table with this entry (to another DB, Server or simply to a file) the Insert_Query has a error: INSERT INTO `test` (`id`, `text`) VALUES ('1',_latin1 0x68656C6C6F209620796F75); This error contains on all tables where the text includes a "–" On the old version of mysql front, the export works fine (with "–" too). |
|
Written by CoS
6 years ago 4 posts since Thu, 12 Apr 07 |
Achso für die, die Deutsch können, sobald ein langer Gedankenstrich im Text vorkommt, entsteht der oben genannte Fehler beim Export. Es scheinen auch noch andere Zeichen betroffen zu sein. Ich habe eine Tabelle mit 512 Texten exportiert und bei 20 einträgen hatte ich diesen Fehler in der query! Nicht in allen dieser Texte kam ein langer Gedankenstrich vor, also sind auch andere Zeichen betroffen, obwohl sie eigentlich zu Latin 1 gehören... Grüße |
|
Written by ansgar
6 years ago 3976 posts since Fri, 07 Apr 06 |
I will analyze that issue asap. |
|
Written by ansgar
6 years ago 3976 posts since Fri, 07 Apr 06 |
Oh I just see that this is not a bug, but a feature - really! I tested it for example with a string "– hallo" and I got this INSERT in an exported file: INSERT INTO `tablename` (`FieldName`) VALUES (_latin1 0x962068616C6C6F); This INSERT re-imports perfectly on my local server. The documentation says that these "introducers" (the character-set in front of the hex-value) are legal for all versions since 3.23, so it cannot be a version issue you encountered. See also http://dev.mysql.com/doc/refman/4.1/en/charset-literal.html What does the error from the server tell you? |
|
Written by CoS
6 years ago 4 posts since Thu, 12 Apr 07 |
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 "– hallo" cant be imported in my local mysql-server!? If i try to execute: INSERT INTO `tablename` (`FieldName`) VALUES (_latin1 0x962068616C6C6F); it brings a error: 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)' at line 1 But if i export the data with mysql-front it works fine!? |
|
Written by ansgar
6 years ago 3976 posts since Fri, 07 Apr 06 |
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. |
|
Written by ansgar
6 years ago 3976 posts since Fri, 07 Apr 06 |
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... |
|
Written by superspace
6 years ago 22 posts since Mon, 28 Aug 06 |
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 |
|
Written by esc
6 years ago 1 posts since Tue, 08 May 07 |
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? |
|
Written by CoS
6 years ago 4 posts since Thu, 12 Apr 07 |
esc wrote: Hi@all 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. |
|
Written by ansgar
6 years ago 3976 posts since Fri, 07 Apr 06 |
esc wrote: 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 . |
|
Written by rosenfield
6 years ago 127 posts since Wed, 24 Jan 07 |
esc wrote: i remotely run a MySQL 4.0x (Linux) and a local 5.1 (WAMP with XAMPP). Both(!) dont understand 0x... 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 ? anse wrote: [...] 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? |
|
Written by grega.sever
6 years ago 1 posts since Thu, 28 Jun 07 |
I have the same problem with characters čČ šŠ and žŽ. It worked well on mySql-Front version Best regards Greg |
|
Written by superspace
6 years ago 22 posts since Mon, 28 Aug 06 |
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 |
|
Please login to leave a reply, or register at first. |