{"id":73021,"date":"2026-05-13T03:01:00","date_gmt":"2026-05-12T17:01:00","guid":{"rendered":"https:\/\/www.rjmprogramming.com.au\/ITblog\/?p=73021"},"modified":"2026-05-11T11:48:22","modified_gmt":"2026-05-11T01:48:22","slug":"mysql-sql-mindset-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/mysql-sql-mindset-tutorial\/","title":{"rendered":"MySql SQL Mindset Tutorial"},"content":{"rendered":"
\"MySql<\/a>

MySql SQL Mindset Tutorial<\/p><\/div>\n

We spend a lot of the working time with this blog in a “what we’d describe as” a …<\/p>\n

\nJavascript mindset\n<\/p><\/blockquote>\n

… which “we’d describe as” …<\/p>\n

\nThis optimistic, and can be chaotic for choice, “anything’s possible”, but is “syntactically logical”, mindset, where Javascript is this “sponge of the Internet” not missing out on anything?! Sound familiar?! Huh?!\n<\/p><\/blockquote>\n

With yesterday’s WordPress Same Action Item Tutorial<\/a> though, we got a bit of a lesson bringing that “Javascript mindset” into an issue where “MySql SQL” was the duck doing all the paddling coming up with a solution to that “Same Cut to the Chase Action Item” dropdown idea.<\/p>\n

We found out, probably four hours later …<\/p>\n

\nRegarding MySql SQL work (which we debug and “live in” the great<\/sup> incredible<\/sub> stupendous<\/sup> phpMyAdmin<\/i><\/a> environment wooooorrrrlllllldddd regarding)<\/font> just because an SQL statement looks “syntactically logical” does not always guarantee success.\n<\/p><\/blockquote>\n

Take a look at …<\/p>\n\n\n\n\n\n
What did not work<\/th>\nError Message<\/th>\n<\/tr>\n
\n
\nSELECT wps_posts.post_title, wps_posts.guid, wps_posts.post_content, LOCATE('\/PHP\/animegif\/tutorial_to_animated_gif.php',wps_posts.post_content) as tfind, LOCATE('\/PHP\/animegif\/tutorial_to_animated_gif.php',wps_posts.post_title) as tother, wps_posts.post_date as post_date FROM wps_posts
\nWHERE wps_posts.post_status = 'publish'
\nAND (1 = 11 OR LOWER(wps_posts.post_title) = LOWER('\/PHP\/animegif\/tutorial_to_animated_gif.php'))
\nAND (wps_posts.post_content like CONCAT(CONCAT('%?p=',wps_posts.guid), '%')
\nOR <\/font>SUBSTRING(wps_posts.post_content,1,240) like '%\/PHP\/animegif\/tutorial_to_animated_gif.php\"%')<\/font> UNION SELECT 'Code Download Table' as post_title, wps_posts.post_content as guid, '' as post_content, 1 as tfind, 0 as tother, CURTIME() as post_date FROM wps_posts
\nWHERE wps_posts.post_status = 'publish'
\nAND LOWER(wps_posts.post_title) = LOWER('\/PHP\/animegif\/tutorial_to_animated_gif.php')
\nAND wps_posts.post_content like '%GETME%' ORDER BY post_date
\n<\/code>\n<\/td>\n		\nMySQL returned an empty result set (ie. zero rows). (Query took 5.8648 seconds).<\/font>\n<\/td>\n<\/tr>\n
Versus what did work<\/th>\n<\/tr>\n
\n
\nSELECT wps_posts.post_title, wps_posts.guid, wps_posts.post_content, LOCATE('\/PHP\/animegif\/tutorial_to_animated_gif.php',wps_posts.post_content) as tfind, LOCATE('\/PHP\/animegif\/tutorial_to_animated_gif.php',wps_posts.post_title) as tother, wps_posts.post_date as post_date FROM wps_posts
\nWHERE wps_posts.post_status = 'publish'
\nAND SUBSTRING(wps_posts.post_content,1,240) like '%\/PHP\/animegif\/tutorial_to_animated_gif.php\"%' UNION SELECT 'Code Download Table' as post_title, wps_posts.post_content as guid, '' as post_content, 1 as tfind, 0 as tother, CURTIME() as post_date FROM wps_posts
\nWHERE wps_posts.post_status = 'publish'
\nAND LOWER(wps_posts.post_title) = LOWER('\/PHP\/animegif\/tutorial_to_animated_gif.php')
\nAND wps_posts.post_content like '%GETME%' ORDER BY post_date
\n<\/code>\n<\/td>\n<\/tr>\n<\/table>\n

… as a case in point?! We tried this ask (can mysql sql return zero rows just because of the overly complex where clause?)<\/a> of Google to try to find out why, regarding “relative database” mindsets this might be so<\/a> …<\/p>\n

\nYes<\/a>, a complex WHERE clause in MySQL can cause a query to return zero rows if it inadvertently filters out all data. This often happens due to logical errors, such as conflicting conditions, NULL values treated as equal to other values, or using NOT IN with subqueries that include NULL.\n<\/p><\/blockquote>\n

Interesting, huh?!<\/p>\n

Perhaps the KISS<\/a> principle should apply here, especially if you are doing MySql SQL outside the original index<\/i>ing<\/sup> database design thoughts ( as we were needing to use here with the MySql SQL function SUBSTRING<\/a> )<\/font>. Also, if we’re into the “blame game” here, question whether a solution you are achieving is inefficient, and wasteful, before applying it as your final offering!<\/p>\n

If this was interesting you may be interested in this<\/a> too.<\/p>\n