(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
Related
What is the purpose of using WHERE COLUMN like '%[_][01][7812]' in SQL statements?
I get some result, but don't know how to use properly.
I see that it is searching through the base, but I don't understand the pattern.
Like selects strings similar to a pattern. The pattern you're looking at uses several wildcards, which you can review here: https://www.w3schools.com/SQL/sql_wildcards.asp
Briefly, the query seems to ba matching any row where COLUMN ends in an _ then a 0 or a 1, then a 7,8,1, or 2. (So it would match 'blah_07' but not 'blah_81', 'blah_0172', or 'blah18')
First thing as you might be aware that where clause is used for filtering rows.
In your case (Where column Like %[_][01][7812]) Means find the column ending with [_][01][7812] and there could be anything place of %
declare
#searchString varchar(50) = '[_][01][7812]',
#testString varchar(50) = 'BeginningOfString' + '[_][01][7812]' + 'EndofString'
select CHARINDEX(#searchString, #testString), #testString, LEN(#testString) as [totalLength]
set #testString = '[_][01][7812]' + 'EndofString'
select CHARINDEX(#searchString, #testString), #testString, LEN(#testString) as [totalLength]
set #testString = 'BeginningOfString' + '[_][01][7812]'
select CHARINDEX(#searchString, #testString), #testString, LEN(#testString) as [totalLength]
Although you've tagged your post MySQL, that code seems unlikely to have been written for it. That LIKE pattern, to me, resembles Microsoft SQL Server's variation on the syntax, where it would match anything ending with an underscore followed by a zero or a one, followed by a 7, an 8 a 1 or a 2.
So your example 'TA01_55_77' would not match, but 'TA01_55_18' would, as would 'GZ01_55_07'
(In SQL Server, enclosing a wildcard character like '_' in square brackets escapes it, turning it into a literal underscore.)
Of course, there may be other RDBMSes with similar syntax, but what you've presented doesn't seem like it would work on the data you've got if running in MySQL.
I'm having trouble building a query in Access 2013. The database isn't mine and the only thing I really have control over is this query. There is a table, I'm pulling 7 fields from it and eventually adding an 8th field to the query to do some string manipulation.
However, I keep getting getting "Syntax error in date in query expression 'fieldname'." error whenever I click on the arrow to sort the fields. The odd thing is these errors pop up when sorting non-date fields. When sorting the date field I get "Syntax error (missing operator) in query expression 'Release Date'."
This happens after a fresh build. I have no WHERE conditions, just SELECT and FROM. Ideas?
Here's the sql query, though I'm mainly working in the query design view:
SELECT Transmissions.[Job#], Transmissions.[Part#], Transmissions.TransmissionSN, Transmissions.Status, Transmissions.[Release Date], Transmissions.[Build Book Printed], Transmissions.[ID Tags Required]
FROM Transmissions;
Well... it seems you are the lucky inheritor of a poorly designed database.
Using special characters in a field name is just asking for trouble. And you've found what that trouble is.
Access uses the # sign to designate a Date type for query comparisons. Such as:
dtSomeDate = #2/20/2017#
You surround the date with the # signs.
In your case, the query thinks [Job#] and [Part#] are trying to wrap dates. But of course, that's not the case and thus it fails.
You can try a couple of work arounds. (I leave it to you to experiment.)
1) You can try to rename the problem fields within your query. So that:
Transmissions.[Job#] becomes Transmissions.[Job#] as JobNum
and
Transmissions.[Part#] becomes Transmissions.[Part#] as PartNum
2) You can try to copy the [Transmissions] table to a new table that you create
that does not have the naming problems.
3) Export the [Transmissions] table to a CSV file and re-import it to a new
table (or possibly new database) without the naming problems.
Here is a link to a microsoft article that tells you why to avoid special characters in Access:
Big Bad Special Chars.
Hope that puts you on the right track. :)
Typically, this means that the field names are missing or misspelled.
Try running this to see:
SELECT * FROM Transmissions;
I'm trying to replicate the following LIKE query using a full text search on JSON data;
SELECT * FROM table
WHERE response LIKE '%"prod_id": "foo"%'
AND response LIKE '%"start_date": "2016-07-13"%'
In my database the above query returns 28 rows
This is my attempt:
SELECT * FROM table
WHERE MATCH(response)
AGAINST('+"\"prod_id\": \"foo\"",+"\"start_date\": \"2016-07-13\""')
However this returns over 4,500 rows (the same as running the first query for only the prod_id ~1,900 rows when running the first query on just the date)
It was my understanding that +"text here" would indicate a required word, and that literal double quotes (present in the JSON data) should be escaped, and that , would indicate a split between the two strings I'm looking for. What am I not understanding correctly? Is there any point in running this as a full text query anyway?
Thanks to #Sevle I've tweaked my query like so, and it's returning the correct results;
SELECT * FROM table
WHERE MATCH(response)
AGAINST('+\"prod_id: foo\" +\"start_date: 2016-07-13\"' IN BOOLEAN MODE)
The comma was not helping and I was escaping the wrong characters, and of course I did need IN BOOLEAN MODE to be added. Finally, I removed the double quotes I was searching for in the JSON string.
It may also be worth noting that as I'm using PHP PDO to run this query I also had to make the following tweaks.
Instead of constructing the query like so trying to bind the variables like I normally would;
$query = $db->prepare('...AGAINST('+\"prod_id: :prod_id\" +\"start_date: :start_date\"');
$query->execute(array('prod_id' => 'foo', 'start_date' => '2016-07-13'));
I had to do this, as I found I could not bind variables in full text searches
$sql_against = $db->quote('...AGAINST('+\"prod_id: foo\" +\"start_date: 2016-07-13\"');
$query = $db->prepare("...AGAINST($sql_against IN BOOLEAN MODE)")
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 \\
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?