I could never understand it, from the second I first heard about people being attacked via remote SQL injection. It's like having a DOS command tagged onto your URL. If you wouldn't allow:
then you shouldn't bloody allow SQL to creep into the URL, POST data, or anything else you intend to act upon.
You want to execute SQL statements based on an input? Okay, make up a language/translation that takes input from your web user and produces a set of SQL stanzas from it. Have external apps send ONLY that language. Have your server translate the language into a set of static PRE-FORMED SQL strings that can never change. Your PHP scripts should not have a single word of SQL in them.
You can now do simple things like: join every single translated SQL stanza in every possible combination and see if it's possible to actually get stuff out of the database that you shouldn't (and this is ASSUMING your SQL is so damn open that any web user can do things like query other tables at all). If you don't want web-users to be able to delete your tables, don't have a translation for it. It is then IMPOSSIBLE for them to do so, because they will never give you anything that corresponds to SQL that you're executing that contains a DROP TABLE statement. It's not in your "language's" vocabulary to even express the idea and you're NEVER interpreting the users input as SQL.
Also, if you delimit all the individual translated stanzas, then there is NO way to produce valid ones that do anything different by concatenating them in strange orders. You can literally fuzz-test those statements on their own and you should never expose anything other than what you intend.
Seriously people, if you don't get this, you shouldn't be managing fecking databases in the first place (the operative word being DATA, as in subject to the Data Protection Act).