enviroument : linux + node 0.10.22 + mysql 5.6.31
recently,there are some wrong result in my database.
Normal results are json strings just like '{"content": "hello,world!", "sender":"warriorA"} '.
Abnormal results are json strings like '{"content": "hello,world!" '.
It looks like there is a part missing.I know the mysql's bug about utf8 and utf8mb4, I guess that's probably why. I confirmed in the production environment that it was emoj. but When I tried to reproduce in the testing environment, I was a little depressed.
in testing environment, the mysql give me an Error “truncated_wrong_value_for_field, Incorrect string value: '\xF0\x9F\x90\xA6,...' for column 'mailParams' at row 1”, not like online.
I don't know how to reproduce and solve this problem, may I have your advice? Thank you very much.
I'm using the "ASC" function in Access (Version 365 Proplus, 32 bit).
Have created a query that uses a table with a post code that needs validating. I'm looking at the first character in the postcode, converting it to ASCII character then planning on filtering out the ones I don't want.
The formula looks like this:-
Site_PostCode_String_Validation_P1: Asc(Left([site_postcode],1))
This works fine and converts as expected. However, when I try sorting or filtering using the Query Criteria on my Ascii list I get the following message:-
"Data Type Mismatch in Criteria Expression"
I have tried converting to a string, for example, using the below:-
Str(Asc(Left([site_postcode],1)))
But this has made no difference, get the same error message when applying criteria or sorting.
I have tried filtering using text and numbers but get the same error.
I have searched here and have Googled but can not see anything relating to the above.
Thanks for any suggestions.
You might simplify it a bit:
Site_PostCode_String_Validation_P1: Asc(Nz([site_postcode], Chr(0))
I tried creating a new table based on the results, thinking that this would then enable me to apply my filtering, during this process I got a more detailed error message stating error due to Null type conversion failure. So then realized that I need to make sure there were no Null entries before doing the ascii conversion. Hopefully this will be of help to someone else. Final formula now works as below:
IIf(IsNull([site_postcode])=-1,Null,Asc(Left([site_postcode],1)))
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.
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.
Somewhere along the line from the DB to the application, this:
sauté
is getting turned into this:
sauté
I'm using Ramaze + Rack + MySQL. I've got a force_encoding plugin set up, so the encoding on the string is UTF-8. If I view the record in the database shell, it's looks fine. The default charset on the table is utf8, and the field itself is "text". The encoding on my database connection is utf8. Also, on my Macbook, everything works great. It's on my Ubuntu server that it's getting mangled. I'm hoping that someone may recognize this and tell me that it's unicode getting turned to ASCII, then back, or something like that.
Most likely your locale differs.
Run the locale command on both and see what's the difference.
I assume you see an issue when you get results back from MySQL, which is a common issue with 1.9 according to google results: http://www.google.com/search?q=mysql+ruby+1.9+encoding.