I just found a bunch of rogue data in my MYSQL db...
The only way to get to it is via one of the columns - FILE_PATH which contains a slash stripped version of a file path. There are a few rogue files in this set that I need find - they all have the file name "Thumbs.db" but they have a variety of paths
example:
F:DatasetGroupedByFormatsx-fmt-398Thumbs.db
I have a full text index on the field, however the following query doesn't give any returns:
SELECT * FROM main_small WHERE MATCH `FILE_PATH` AGAINST ('Thumbs.db')
Response:
MySQL returned an empty result set (i.e. zero rows). ( Query took 0.0382 sec )
I am unsure whether this is because I have the syntax wrong, or whether the text string needs to be isolated by whitespace/punctuation.
Surely it's
select * from main_small where FILE_PATH like '%Thumbs.db'
However, if not then does MySql Full text Search help?
The problem is that your query thinks 'Thumbs.db' is a whole word. You'll need to find some way to do wildcard searching in order to select those rows. How about:
SELECT * FROM main_small WHERE `FILE_PATH` LIKE '%Thumbs.db'
Just use LIKE:
SELECT * FROM main_small WHERE `FILE_PATH` LIKE '%Thumbs.db'
Related
I have a table where the field "company_name" has weird characters, like "à","ö","¬","©","¬","†", etc. I want to return all "company_name"s that contain these characters anywhere within the string. My current query looks like this:
SELECT * FROM table WHERE
MATCH (company_name) AGAINST ('"Ä","à","ö","¬","©","¬","†"' in natural language mode);
But I keep getting no data from the query. I know this can't be the case, as there are definitely examples of them I can find manually. To be clear, the query itself isn't throwing any errors, just not returning any data.
The minimun word length is 3 pr 4 .
you can change it see manial
https://dev.mysql.com/doc/refman/8.0/en/fulltext-fine-tuning.html
or use regular expressiions
SELECT * FROM table WHERE
ompany_name REGEXP '[Äàö¬©¬†]+';
SELECT *
FROM table
WHERE company_name LIKE '%[^0-9a-zA-Z !"#$%&''()*+,\-./:;<=>?#\[\^_`{|}~\]\\]%' ESCAPE '\'
This will find any wacky stuff, including wide characters or 'euro-ASCII' or emoji.
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.
I have a database of information about images. I need to allow users to search for file names that contain a user-specified character string. It's not working the way it appears it should.
For example, the database contains 27 records for files whose names begin with the letter 'b'.
If I execute (in PHPMyAdmin) the query:
SELECT * FROM image WHERE img_name LIKE '%b%';
I get a list of records whose file names contain the letter 'b' (as expected).
But only 4 of the 27 records for files starting with 'b' show up in that list.
Any idea what I'm missing?
After I posted the question, another possibility occurred to me, which turned out to be the solution.
I looked further into the database definition (I did not design it), and it uses varbinary(255) for img_name. If I change the query to:
SELECT * FROM `image` WHERE CONVERT(img_name USING latin1) LIKE '%b%'
I get all of the records that I expect.
You say that the ones that aren't showing up are ones that start with a 'b'.
This could be a case issue.
Convert the name to lower case like so
SELECT * FROM image WHERE strtolower(img_name) LIKE '%b%';
I have a file-path search, allowing a user to search his/her files on a website. Example entries are:
`path`
- /Volumes/Fulfill/03-01-13/FILFILE.txt
- /Volumes/Master/.Trash/Weeds.mov
If someone search for "master mov" it would do the following query:
SELECT * FROM files WHERE path LIKE '%master%' AND path LIKE '%mov%'
and would return:
- /Volumes/Master/.Trash/Weeds.mov
What would be a better way or method to do the above search?
Update: I tried doing the following, but my implementation of the MYISAM FULLTEXT search didn't work well at all:
select * from path where path like '%red%' and path like '%state%' <-- works
select * from path where match(path) against ('red state'); <-- zero results
Is there another way to implement full text search than the above?
% is a wildcard. It will be faster if you replace it with something like this:
SELECT * FROM files WHERE path LIKE '/Volumes/Master%mov'
Because you're not checking for more conditions.
Update
For Full Text option you would (one time)
ALTER TABLE files ADD FULLTEXT(path);
Then for the searches you would
SELECT * FROM files
WHERE MATCH (path)
AGAINST ('+Master +mov' IN BOOLEAN MODE);
Short words are ignored, the default minimum length is 4 characters. You can change the min and max word length with the variables ft_min_word_len and ft_max_word_len
I am struggling with this query and want to know if I am wasting my time and need to write a php script or is something like the following actually possible?
UPDATE my_table
SET #userid = user_id
AND SET filename('http://pathto/newfilename_'#userid'.jpg')
FROM my_table
WHERE filename
LIKE '%_%' AND filename
LIKE '%jpg'AND filename
NOT LIKE 'http%';
Basically I have 700 odd files that need renaming in the database as they do not match the filenames as I am changing system, they are called in the database.
The format is 2_gfhgfhf.jpg which translates to userid_randomjumble.jpg
But not all files in the database are in this format only about 700 out of thousands. So I want to identify names that contain _ but don't contain http (thats the correct format that I don't want to touch).
I can do that fine but now comes the tricky bit!!
I want to replace that file name userid_randomjumble.jpg with http://pathto/filename_userid.jpg So I want to set the column user_id in that row to a variable and insert it into my new filename.
The above doesn't work for obvious reasons but I am not sure if there is a way round what I'm trying to do. I have no idea if it's possible? Am I wasting my time with this and should I turn to PHP with mysql and stop being lazy? Or is there a way to get this to work?
Yes it is possible without the php. Here is a simple example
SET #a:=0;
SELECT * FROM table WHERE field_name = #a;
Yes you can do it using straightforward SQL:
UPDATE my_table
SET filename = CONCAT('http://pathto/newfilename_', userid, '.jpg')
WHERE filename LIKE '%\_%jpg'
AND filename NOT LIKE 'http%';
Notes:
No need for variables. Any columns of rows being updated may be referenced
In mysql, use CONCAT() to add text values together
With LIKE, an underscore (_) has a special meaning - it means "any single character". If you want to match a literal underscore, you must escape it with a backslash (\)
Your two LIKE predicates may be safely merged into one for a simpler query