Export Error
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 "
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.
Just having to do some further googling...
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?
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?
Please login to leave a reply, or register at first.