I have a field in a mysql database with a strange value:
????!"?;%:?*()_+,??????/????\/
The problem is I cannot select it - the following statement returns no rows
SELECT *
FROM `pool_tag` AS `Extent1`
where `Extent1`.`PoolTag`='????!"?;%:?*()_+,??????/????\/'
The value contains "
I was trying also to use rule to duplicate cotation sign, so used this sql
SELECT *
FROM `pool_tag` AS `Extent1`
where `Extent1`.`PoolTag`="????!**""**?;%:?*()_+,??????/????\/"
(note double cotation marks on position 6)
But still no result
The other problem might be, even if I find a specific syntax to handle in sql query directly, I need to select this from Entity Framework (actually the query you saw wa generated by EF)
Any idea how to handle this?
EDIT
I found about mysql escape chars, I checked all one by one (", ', \, %) and I dicovered that % cause the problems.
If I remove it from both field and search value, sql works
If I leave it in field, and try to escape it in sql select, code still don't work
e.g.
SELECT *
FROM `pool_tag` AS `Extent1`
where `Extent1`.`PoolTag`="????!?;\%:?"
does not find the value
????!?;%:?
Any idea why?
Related
1. select count(*) from tableX where code = "XYZ";
2. select count(*) from tableX where code like "%XYZ";
Result for query 1 is 18734. <== Not Correct
Result for query 2 is 93003. <== Correct
We know that query 2's count is correct based on independent verification.
We expect these two queries to have the exact same count for each because we know that no rows in tableX have a code that ends with "XYZ", so the wildcard at the beginning shouldn't affect the query.
Why would these queries produce different counts?
We have already researched the differences between "=" comparison and "like" string comparison, but based on all our verification checks, we still don't understand why this would give us different counts
We have confirmed the following:
There are no leading or trailing characters in the "code" field
There are no hidden characters (tried all found here: How can I find non-ASCII characters in MySQL?)
The collation is "utf8_unicode_ci"
We are using MySQL version 5.5.40-0ubuntu0.12.04.1.
Try this in order to get your answer:
SELECT code
FROM tableX
WHERE code LIKE "%XYZ"
AND code <> "XYZ"
LIMIT 10
My guess is that some of your codes end with a lowercase xyz, and since LIKE is case-insensitive, it matched these where = did not.
where code = "XYZ"; gives exact match whereas where code LIKE "%XYZ"; includes partial match as well. In your case, there could be an extra space present which is giving wrong count. Consider trimming before comparing like
where UPPER(TRIM(code)) = 'XYZ';
We restarted the server that the database resides on, we re-ran the queries, and now they all are producing the expected, correct results...
We'll have to look into possibilities for why this "fixed" the issue.
So I have a table called "lu_regex" with a column called "regex"
Select * from lu_regex;
athedsl-\d+
i5[93][0-9a-fA-F]+\.versa
5ac[a-f0-9]+.+sky
The table contains 1000's of rows, with various Regular Expressions syntax, i'm just showing three in this example.
Now I'm trying to take user input and match that input against the rows in the table. So I'm doing this.
SELECT * FROM lu_regex where '5aca3a11.bb.sky.comr' regexp regex;
regex
5ac[a-f0-9]+.+sky
1 row returned.
I'm getting back what I expected, with that query, then I try this one.
SELECT * FROM lu_regex where 'athedsl-07371.home.otenet.gr' regexp regex;
0 rows returned.
It should match on "athedsl-\d+", but i'm assuming it has something to do with the "\d". I even tried adding this to the database "athedsl-\\d+" and that didn't cause a match either.
I'm trying to stick to a MySQL solution, what am I doing wrong, this should be possible.
I just found this link, it looks like a bug that hasn't been fixed. It was verified in 2013.
https://bugs.mysql.com/bug.php?id=70413
Bug #70413 \d is not working in REGEXP for a MySQL query
I think the solution is going to be is to replace all \d with [0-9]
I am trying to retrieve a list of database records which have specific 'interest codes' inside of the 'custom_fields' table. So for example right now there is 100 records, I need the Name, Email and Interest Code from each of those records.
I've tried with the following statement:
SELECT * FROM `subscribers` WHERE list = '27' AND custom_fields LIKE 'CV'
But with no luck, the response was:
MySQL returned an empty result set (i.e. zero rows). ( Query took 0.0003 sec )
You can see in this screenshot that at-least two rows have 'CV' inside custom_fields. Whilst within the database it's not called 'Interest Code', that's what they are so therefore why I am referencing it in this way.
You need to enclose your "search string" inside some wildcards:
select * from subscribers where list=27 and custom_fields like '%CV%';
The % wildcard means "zero or more chacarcters at this position". The "_" wildcard means "a character in this position". Please read the reference manual on the topic. Also, you may want to read about regular expressions in MySQL for more complex string comparissons.
(Sorry for the longish question, I'll try to be concise.)
I'm running SQL Server Profiler and I'm chasing down some performance issues. I'm relatively new to what the profiler does and I've exported the traces into a table so I can run queries against the data.
One thing I've been running up against is some seemingly odd behavior doing select queries against the TextData field of the table generated by the trace export. It may have to do with the field's data type (ntext, null). I'm selecting for particular values, but getting unexpected results. For example, if I do this:
select * from [TraceAnalyzer].dbo.TraceTable
and I'm interested in values like this:
exec [Sproc_of_interest] #parm1=992
I'd do a query like this:
select * from [TraceAnalyzer].dbo.TraceTable
where TextData like '%exec [Sproc_of_interest] #parm1=%'
but the return result is empty.
Also, if I do a query like:
select * from [TraceAnalyzer].dbo.TraceTable
where TextData like '%exec [Sproc_of_interest]%'
I get unexpected TextData values like exec sp_reset_connection
Would the square brackets in the criteria be messing things up? I've tried omitting them, but that just excludes everything. I'm not aware of escape characters in SQL select queries, but when I copy/paste the value from one of the offending records, the pasted value does not appear to contain anything that would meet the original query's criteria.
Any insights would be greatly appreciated. Thanks.
[Sproc_of_interest] in the pattern syntax is interpreted as matching one character that is in the set S,p,r,o,c,_,o,f,_,i,n,t,e,r,e,s,t.
Three possible ways of solving this are below.
1) Escape [ with square brackets
LIKE '%exec [[]Sproc_of_interest] #parm1=%'
2) Use an escape character
LIKE 'exec \[Sproc_of_interest] #parm1=' ESCAPE '\'
3) Use CHARINDEX instead of escaping anything
WHERE CHARINDEX('exec [Sproc_of_interest] #parm1=' , TextData) > 0
I have this string: alexandre.aba\40gmail.com#gtalk.ofelia.dcc.fc.up.pt stored as JabberID in USER table in my database.
The problem is when i execute this query:
SELECT * FROM `USER` WHERE JabberID='alexandre.aba\40gmail.com#gtalk.ofelia.dcc.fc.up.pt'
It returns:
MySQL returned an empty result set (i.e. zero rows).
I think it's the \40 that is causing the problem but i don't know how to fix it.
You should think about using prepared statements instead since it's safer but to correct the current string look at the link http://dev.mysql.com/doc/refman/5.1/en/string-literals.html for a list of special characters.
I think the \ should be replaced with \\