I have to second prepared statements. You wont have to change your code too much to use them and they are way too important not to use. They can even lead to speedups if you're going to reuse queries.
Apologies for the confusion I am not actually using a SQL cleaner, in-fact with brutal honesty I don’t actually know what one is. I was using the term to reference my usual methods/techniques for keeping SQL ‘clean’ from injection attempts.
I am fairly happy with my current SQL setup and the way it protects from injection, obviously when I code it correctly, however I will certainty look into using fully prepared SQL, currently I do something ‘similar’ using my objects so it would probably be very easy to implement.
Thanks for all of the feedback so far and pointing out the flaws, in fact the logs I have gotten from people ‘testing’ my SQL protection has helped a lot!
In all seriousness: you shouldn't be, because it clearly doesn't protect in all cases. ("Failed to wrap a query in a magic function to make it sort of safe" is part of "all cases.") You have demonstrated, by neglecting to use your "correct SQL protection techniques," why non-prepared statements are absolutely terrible. You cannot have the error you just did if you train yourself not to use direct SQL queries, regardless of library. Querying via MDB2 or PDO (or doctrine-dbal, which is a superset of PDO) means you have to intentionally and willfully do something very out-of-the-ordinary to pass in raw data as a SQL query, instead of being forced to wrap your queries in some slipshod, maybe-works-maybe-doesn't homegrown function that has not been rigorously tested.
Don't reinvent the wheel. Safe SQL queries are a solved problem.
I will certainly look at none direct SQL, however I just don't feel it's my number 1 priority at the moment, especially when the template isn't even rendering in some browsers.