I'm experiencing a weird hex string result when trying to concat a string with a column that should be of LONGTEXT type.
The query goes like this:
SELECT concat("abc",t.LONGTEXT_VALUE,"cde") FROM mytable t
61626354657374696e67636465
The hex string 61626354657374696e67636465 is the correct value, just in hexadecimal form.
A SELECT on the column itself will return the normal string:
SELECT t.LONGTEXT_VALUE FROM mytable t
Testing
Have you tried casting? Usually works pretty well for me. Example:
SELECT CONCAT("abc",CAST(t.LONGTEXT_VALUE AS CHAR),"cde") FROM mytable t
When you concat a number without a cast it returns as a blob. This is intended functionality of MySQL as far as I can tell since, it was reported in this bug thread and they closed it and confirmed it was returning a Blob.
Related
I have a field in my MySQL database that is set to data type "BIT". The value in the field is 101101. I am trying to read this value using Coldfusion (version 11)
I simply use the following code:
<cfquery name=q1 datasource=#data_source#>
select * from mytable
</cfquery>
<cfoutput>
#q1.mybitfield#
</cfoutput>
I have tried using CAST and CONVERT on the MySQL side and I have tried CharSetEncodeing on the CF side along with every option of ToString, ToBase64, and ToBinary that I can think of.
I still can not get my output to look like it does in the database.
Actually, I was probably thinking of SQL Server's bit type. For MySQL, a simpler option might be to use the bin() function which:
Returns a string representation of the binary value of N, ...This is equivalent to CONV(N,10,2). Returns
NULL if N is NULL.
For example:
SELECT bin(YourBitColumn) AS YourBitColumn FROM YourTable
... or
SELECT bin(YourBitColumn+0) AS YourBitColumn FROM YourTable
NB: High-order 0 bits are not displayed in the converted value. That applies the CF function as well.
Thanks Leigh for your help. I was never able to get it to work with just one step so I used a two step solution (if you want to call it that). What I ended up doing was setting up my MySQL statement to convert the field to an Unsigned interger (although Decimal or a signed integer would have also worked), then once I read in the decimal value I was able to convert it to binary using your suggestion of FormatBaseN(q1.myfield,2). So thanks for the reminder of FormatBaseN. I had forgotten about that one.
My final code ended up looking like this:
The MySQL statement:
SELECT *, CONVERT(item , UNSIGNED) as di from mytable
And the Coldfusion looked like this:
<cfset d = FormatBaseN(q1.di, 2)>
Edit
After writing this, I decided to go with Leigh's answer above since it was a better solution.
I'm trying to find a way to run a query which selects where the first two characters of an eight character string are Not numeric.
I've found a way to select if the entire string is numeric:
SELECT str FROM tbl
WHERE str REGEXP('(^[0-9]+$)');
So from my limited knowledge of regex I'm guessing that I'll need to use something like:
SELECT str FROM tbl
WHERE str REGEXP('(^[A-Z]+$)');
(I'm OK to use capitals for this as thats how the codes are stored)
I just don't know how to apply this test to just the first 2 characters of the string instead of the entire string?
^[A-Z]{2}
Try this.This should do it.
Good Day,
I am trying to get a point from an SQL column. CUrrently it is encoded as a string of characters: Gþ`C#Ëóàî¬Ë]À
So is there any way to actually decode it to get the actual value?
Use MySQL's AsText() function:
SELECT AsText(myPoint) FROM myTable
I would like to SELECT a table row by searching a Blob's hex string value. I have a blob value that I want to find whose hex representation is 0041b074351bfa1092fd740c146f26ae. I would like to able to SELECT for this row by typing all or part of the string. Is this possible?
Try this:
SELECT *
FROM t1
WHERE UNHEX(hex_col) LIKE '%value%';
ps: It can be really slow when comes to performance. Be careful.
;-)
Simple query is working fine for me.. Please try like this
EG.
SELECT *
FROM YOUR_TABLE_NAME_HERE
WHERE YOUR_BLOB_FIELD_NAME_HERE LIKE '%SEARCH_TEXT_HERE%'
What really is the difference between MySQL UNHEX and X when dealing with hexadecimal values in a database?
Eg.
SELECT * FROM test WHERE guidCol IN (UNHEX('hexadecimalstring'));
SELECT * FROM test WHERE guidCol IN (X'hexadecimalstring');
Both gives me exact result set. So is there any difference? Performance implications?
Edit: the underlying type of guidCol is binary of course
UNHEX() is a function, therefore you can do something like
SET #var = '41';
SELECT UNHEX(#var);
SELECT UNHEX(hex_column) FROM my_table;
X, on the other hand, is the syntax for a hexadecimal litteral. You cannot do this:
SET #var = '41';
SELECT X#var; -- error (string litteral expected)
SELECT X'#var'; -- error (`#` is not a hexadecimal digit)
SELECT X(#var); -- returns NULL, not too sure about the reason... [edit: but this is probably why you are inserting NULL values]
SELECT X(hex_column) FROM my_table; -- returns NULL as well
This explains why you always get better performance with X: you are using a language construct instead of a function call. X does not need to evaluate a variable, since it expects a litteral string.
Note that even in MySQL 5.6, the X'' notation has a length limit in the reference mysql client and UNHEX() does not (appear to). I do not know what the limit is for X'', as it is not officially documented but I have encountered it when trying to INSERT a BLOB. With X'' literal, mysql client threw a syntax error with a sufficiently long hex sequence while UNHEX() of the same sequence did not. Obviously, length is not an issue when it comes to an actual GUID, but I figured this is useful for anyone else using this question to answer mysql insertion of binary data in the general case.