I am using MySQL Workbench (6.2.3) and I am using ExtractValue() to grab data from an XML string. Using code similar to:
Select
Table2.user_id,
ExtractValue(TableName, '//CustomerSource//LeadID') as LeadID.
ExtractValue(TableName, '//CustomerData//City') as City
From
Schema.Tablename,
Schema2.Table2
Where
Tablename.TransactionID = Table2.TransactionID
;
When the output is delivered, all values created using ExtractValue are viewed as BLOB. When viewing these BLOBs in the viewer, the data is correctly displayed.
I have already tried treating BINARY/VARBINARY values as non-binary strings.
Does anyone know a workaround, fix, or reason that these values are displayed as BLOB?
Also, this code works on older MySQL Workbench installations just fine. I would attempt to install an earlier version, but this is for my team at work and it would be easier to just direct them to the most updated install of MySQL Workbench.
Thank you in advance,
I'm not 100% sure what you are really asking, but assume you don't want to show the extracted values as BLOBs. Solution: try casting the result to a varchar.
Related
When I execute the example from http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_subtime I don't get the answer in the format shown there. This is the example:
mysql> SELECT SUBTIME('2007-12-31 23:59:59.999999','1 1:1:1.000002');
-> '2007-12-30 22:58:58.999997'
But the answer I get is:
323030372d31322d33302032323a35383a35382e393939393937
If you remove every second letter from that answer you get
2007d12d30022a58a58e999997
...which is almost the expected string. Maybe the conversion from some internal format to the actual representation goes somehow wrong?
I used PhpMyAdmin to execute the SELECT on my provider's web server. With PhpMyAdmin on my local machine it works correctly, i.e. as shown in the MySQL docs.
EDIT: The answer I get is actually the string representation of the hexadecimal character values of the DATETIME string, see http://www.asciitable.com/. But I still don't know how that happens.
I believe the issue you're talking about is this one: https://github.com/phpmyadmin/phpmyadmin/issues/6321 which will be fixed in version 4.6.0. I've just tested with the pre-release version of 4.6.0 and it looks correct, so I suggest upgrading once 4.6.0 comes available.
I'm using a GUI MySQL manager called Sequel Pro on my Mac.
Historically, when I'd right-click a row and click "Copy as SQL Insert", it would copy a standard-looking MySQL insert statement containing the row contents in plain text.
I noticed the other day when doing this, the output now looks like this:
INSERT INTO `config` (`key`, `value`)
VALUES
(X'68656C6C6F5F737461636B5F6F766572666C6F77', X'5468616E6B7320666F7220616E73776572696E67206D79207175657374696F6E');
What is with the random letter/number strings beginning with X? Starting a string with an X doesn't look like standard SQL syntax. Somehow though, when I run the SQL command it enters a valid new record with the data I would expect into the table.
What feature is this, what benefit does it serve, and why did it suddenly change since last week?
It's a SQL standard to escape binary literals in the format:
x'hexstring'
Like the following:
x'68656C6C6F5F737461636B5F6F766572666C6F77'
According to a comment on the documentation for the BINARY and VARBINARY Types, MySQL also supports the ODBC standard:
0x68656C6C6F5F737461636B5F6F766572666C6F77
I have been tasked with migrating a Microsoft SQL Server 2005 database to MySQL 5.6 (these are both database servers runnig locally) and would really appreciate some help.
-MSSQL source database has latin1 collation (so has ISO 8859-1 character set right?) but doesn't have any char/varchar fields (any string field is nvarchar/nchar) so all this data should be using the UCS-2 character set.
-MySQL target database wants the character set UTF-8
I decided to use the database migration toolkit in the latest version of the MySQL workbench. at first it worked fine and migrated everything as expected. But I have been totally tripped up upon encountering UCS-2 surrogate pair characters in the MSSQL database.
The migration toolkit copytable program did not provide a very useful error message: "Error during charset conversion of wstring: No error". It also did not provide any field/row information on the problem-causing data and would fail within chunks of 100 rows. So after searching through the 100 rows after the last successful insert I found that the issue seemed to be caused by two UCS-2 characters in one of the nvarchar fields. They are listed as surrogate pairs in the UCS-2 character set. They were specifically the characters DBC0 and DC83 (I got this by looking at the binary data for the field and comparing byte pairs (little endian) with data that was being migrated successfully).
When this surrogate pair was removed from the MSSQL database the row was migrated successfully to MySQL.
Here is the problem:
I have tried to search for these characters in a test MSSQL table (this chartest table is just various test strings an nvarchar field) to prepare a replacement script and keep getting strange results... I must be doing something incorrectly.
Searching for
SELECT * FROM chartest WHERE text LIKE NCHAR(0xdc83)
Will return any surrogate pair character (whether or not it uses DC83), but obviously, only if it is the only character (or part of the pair) in that field. This isn't a big deal since I would like to remove any instance of these anyway (I dont like to remove data like this but I think we can afford it).
Searching for
SELECT * FROM chartest WHERE text LIKE '%' + (NCHAR(0xdc83))+ '%'
Will return every row! Regardless of whether it even has a unicode character present in the field let alone the DC83 character. Is there a better way to find and replace these characters? Or something else I should try?
I have also tried setting the target databse, table, and field character set to UCS-2 but it seems as though it does not make a difference.
I should also mention that this migration is using live data (~50GB database!) while one of the sites that feeds it is taken offline so any solutions to this need to have a quick running time...
I would appreciate any suggestions very much! Please let me know if there is any information I have left out.
I had this error, and now I have discovered the source of the problem. I had a hard time finding out, so maybe this will be useful to someone, even though I realize, my problem and workaround may not be spot on matching op's original trouble.
I am migrating data from MSSQL to MySQL, and the content being migrated is html-content from Sitecore CMS (target CMS is Drupal, btw).
I've found, that I get this error when converting the database and hitting records, that contain Instagram-embeds. Instagram-embeds work in the way, that the embedded post data is copied to the embed code (instead of being loaded async., et.c. - even the image is included as base64-css...), and the young people nowadays tend to put a lot of emoji's in their image-descriptions (using their iPhones with Emoji keyboard). Emoji's are represented by 4-byte encoded characters, but MySQL utf8 only allows for 3-byte encoded unicode characters.
My initial error from running wbcopytables.exe (which is the non-GUI way of doing Migration Wizard in MySQL Workbench) was the
Error during charset conversion of wstring: No error
but upgrading MySQL Workbench to recent version (from 5.something to 6.x) makes the error a bit more descriptive, hinting table and column (alas, not row):
ERROR: Could not successfully convert UCS-2 string to UTF-8 in table
[MyDatabase].[dbo].[MyTable] (column MyColumn).
Original string: ...
Anyway - a solution *could* be to use utf8mb4 which would allow for the emoji's. Read more here.
But it looks like, it's a bad idea to do this in e.g. my case with Drupal.
So - the solution I ended up with was simply to strip these characters in my migrate-script. There is no point in keeping these for users of the site in question, since they are being displayed as rectangles on the webpage anyway. Since you can't search-and-replace with regex in SQL Server, I processed the data using a DAL and c# .NET, and I found the help here (thanks a ton, Jon Skeet) - turns out there is a regex-pattern for matching one half of a surrogate pair in UTF-16. See below (and use the pattern in another language if needed).
var noUcs2SurrogatePairsString = Regex.Replace(stringWithUcs2SurrogatePairs, #"\p{Cs}", string.Empty);
I had a very similar problem today, and I found that it was caused by empty strings, replaced them with NULLs or a value representing no data and the migration worked fine.
I solved just editing the "import data script.cmd" where it reads columns "As NVARCHAR" by replacing those with "VARCHAR" only.
Note: My table columns was VARCHAR type already, so... for some stupid reason the migration script improperly cast it to UNICODE (NVARCHAR) type.
This issue has now been resolved. I used user Remus Rusanu's suggestion here for finding the rows with these surrogate pair characters using CHARINDEX and have decided to use SUBSTRING to exclude the troublesome characters like so:
UPDATE test
SET a = SUBSTRING(a, 1, (CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000)))+1)/2 - 1) -- string before the unwanted character
+ SUBSTRING(a, (CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000)))+1)/2 +1, LEN(a) ) -- string after the unwanted character
WHERE CHARINDEX(0x83dc, CAST(a AS VARBINARY(8000))) % 2 = 1 -- only odd numbered charindexes (to signify match at beginning of byte pair character)
actually I try to insert Chinese data to sqlite3 from ActionScript3 using CGI webservice script. for inserting English data it's working fine. But when I try to insert Chinese data, the URL goes like this /cgi-bin/reg.cgi?username=%E5%A5%A0%E5%9F%BA%E6%95%88%E6%9E%9C%E5%9B%BE
and python script shows that update Error. I just googled and got a idea to use encodeURIComponent("奠基效果图"); . When I use encodeURIComponenet it's insert data into my database as like this %E5%A5%A0%E5%9F%BA%E6%95%88%E6%9E%9C%E5%9B%BE . And also I tried byteArray.writeUTF("奠基效果图"); , but when use writeUTF() my URL value goes Null. I think I need to use encode UTF-8. But I don't know how to use that on Action Script. kindly some one suggest some idea to solve this problem. thanks in advance.
Do not think about the format which is stored in the Data Base, when you use the encodeURIComponenet(str) for encoding data, you just use decodeURIComponent(rstr) for retrieve from data base. it can retrieve the data with decoded fromat. I think this one helps.
I'm using MySQL Workbench CE 5.2.30 CE / Rev 6790 . When execute the following statement:
SELECT OLD_PASSWORD("test")
I only get back a nice BLOB icon, I need to left-click to select the cell, right-click and choose "Open Value in viewer" and select the "Text" tab.
Using the same with phpMyAdmin, I get directly back the value of the OLD_PASSWORD call. It's just an example, but is there a way to directly see such results in the output?
In short:
Go to Edit > Preferences
Choose SQL Editor
Under SQL Execution, check Treat BINARY/VARBINARY as nonbinary character string
Restart MySQL Workbench (you will not be prompted or informed of this requirement).
In MySQL Workbench 6.0+
Go to Edit > Preferences
Choose SQL Queries
Under Query Results, check Treat BINARY/VARBINARY as nonbinary character string
It's not mandatory to restart MySQL Workbench (you will not be prompted or informed of this requirement).*
With this setting you will be able to concatenate fields without getting blobs.
I think this applies to versions 5.2.22 and later and is the result of this MySQL bug.
Disclaimer: I don't know what the downside of this setting is - maybe when you are selecting BINARY/VARBINARY values you will see it as plain text which may be misleading and/or maybe it will hinder performance if they are large enough?
I'm not sure if this answers the question but if if you right click on the "blob" icon in the field (when viewing the table) there is an option to "Open Value in Editor". One of the tabs lets you view the blob. This is in ver. 5.2.34
Perform three steps:
Go to "WorkBench Preferences" --> Choose "SQL Editor" Under "Query Results": check "Treat BINARY/VARBINARY as nonbinary character string"
Restart MySQL WorkBench.
Now select SELECT SUBSTRING(<BLOB_COLUMN_NAME>,1,2500) FROM <Table_name>;
casting works, but it is a pain, so I would recommend using spioter's method unless you are using a lot of truly blob data.
SELECT CAST(OLD_PASSWORD("test") AS CHAR)
You can also cast as other types, and even restrict the size, but most of the time I just use CHAR:
http://dev.mysql.com/doc/refman/5.5/en/cast-functions.html#function_cast
select CONVERT((column_name) USING utf8) FROM table;
In my case, Workbench does not work. so i used the above solution to show blob data as text.
Doesn't seem to be possible I'm afraid, its listed as a bug in workbench:
http://bugs.mysql.com/bug.php?id=50692
It would be very useful though!
had the same problem, according to the MySQL documentation, you can select a Substring of a BLOB:
SELECT id, SUBSTRING(comment,1,2000) FROM t
HTH, glissi
I pieced a few of the other posts together, as the workbench 'preferences' fix did not work for me. (WB 6.3)
SELECT CAST(`column` AS CHAR(10000) CHARACTER SET utf8) FROM `table`;
Work bench 6.3
Follow High scoring answer then use UNCOMPRESS()
(In short:
1. Go to Edit > Preferences
2. Choose SQL Editor
3. Under SQL Execution, check Treat BINARY/VARBINARY as nonbinary character string
4. Restart MySQL Workbench (you will not be prompted or informed of this requirement).)
Then
SELECT SUBSTRING(UNCOMPRESS(<COLUMN_NAME>),1,2500) FROM <Table_name>;
or
SELECT CAST(UNCOMPRESS(<COLUMN_NAME>) AS CHAR) FROM <Table_name>;
If you just put UNCOMPRESS(<COLUMN_NAME>) you can right click blob and click "Open Value in Editor".
there is few things that you can do
SELECT GROUP_CONCAT(CAST(name AS CHAR))
FROM product
WHERE id IN (12345,12346,12347)
If you want to order by the query you can order by cast as well like below
SELECT GROUP_CONCAT(name ORDER BY name))
FROM product
WHERE id IN (12345,12346,12347)
as it says on this blog
http://www.kdecom.com/mysql-group-concat-blob-bug-solved/
NOTE: The previous answers here aren't particularly useful if the BLOB is an arbitrary sequence of bytes; e.g. BINARY(16) to store 128-bit GUID or md5 checksum.
In that case, there currently is no editor preference -- though I have submitted a feature request now -- see that request for more detailed explanation.
[Until/unless that feature request is implemented], the solution is HEX function in a query: SELECT HEX(mybinarycolumn) FROM mytable.
An alternative is to use phpMyAdmin instead of MySQL Workbench - there hex is shown by default.