I already told you there's no weakness in a single line of code, as there are no bugs in one either.
Read the Cheat Sheet to know how to bypass " ' and ; escaping, Which is what real_escape_string does.
There's a big text manual namely "OWASP testing guide" available as PDF through OWASP wiki. I suggest you read that first, Since Security is not like an algorithm that you implement. It's something that should be taken care of amongst the whole SDLC.
Let me explain a bare scenario here:
You've taught a few developers how to use escape_string and prevent injections. They have a bad habit of concatenating string, So they concat them and escape, And it won't work. Then they escape them and concat, And it works.
But this is a very common SQL statement: SELECT * FROM footable WHERE ID=5
And tada! You can inject everything here.
Ok now you see this and tell you developers to insert everything as strings, Even "'".date("Y-m-d H:i:s")."'", And so they do. After a few works, They get bored and do something like this:
SELECT * FROM foo WHERE ID=$pagenumber
and they get pagenumber form a cookie or something. A developer would never think that a cookie would contain injections, I've seen million of cases where developers simply check for validity of an input field with max length of 4 which is supposed to have numbers on client side, and assume it's safe afterward.
The point is, Developers are not security experts, And they are not intended to be. A developer is paid a certain fee, And an app security expert is paid much more. If we had had all our developers enough training to be the same as security experts, Then we never needed any framework or wrapping for security.
And one last point, Just to let you know, Many major development platforms e.g. Google Gears have cut out the use of SQL Queries and only allow you to use Prepared Statements.
regards