You could argue that the major source of insecure code these days is old answers on stackoverflow which show vulnerable examples. Though, i believe there was an initiative to go back and change old answers which posted vulnerable code but not sure if that ever took off.
Some URLS:
As you said SQL server, i literally googled microsoft ado.net example, first result is showing how to use parameterized queries: https://docs.microsoft.com/en-us/dotnet/framework/data/adone...
Googled the same with sql injection/security: huge article on it all https://social.technet.microsoft.com/wiki/contents/articles/...
As an (ex) security professional myself, i definitely agree with the guy above saying that these days in general you do see a lot less of the "schoolboy" vulnerabilities. Definitely still out there though, even in tier 1 public-facing websites of global banks, but certainly not widespread, and certainly not ubiquitous. I'd say this is due to a combination of hand-holding in frameworks, and better education all round.
Some ORMs are powerful and even have subsets of language for data transformation, and so on... And now you have even another problem: another layer of abstraction that might fail or have their own bugs and security issues.
I miss writing pure and simple SQL queries whenever I'm forced to use an ORM. This is one of the things I enjoy in the Go ecosystem: if you want SQL, probably go with database/sql and write SQL directly instead of any fancy ORMs out there.
Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead.
And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later.
I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean.
For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.