I previously worked on an extremely large (in whatever sense you wish to look at, size of codebase, number of users, transaction volume, whatever) system that w

I previously worked on an extremely large (in whatever sense you wish to look at, size of codebase, number of users, transaction volume, whatever) system that was originally written in a language like you describe: Pro*C. It basically permitted in-lining SQL with your C code. It might've not been too bad on small systems, but shared Cs scaling problems. It was difficult to track where database changes were actually coming from, but I don't know of any other solution that would have made that easier. If you have a dozen applications across tens of millions of lines of code, all of which could potentially be responsible (or maybe whatever wrote the value they based their change off of was actually the problem...) things get hairy. I am curious if you've looked at C# and their LINQ stuff though as it sounds like it might check a lot of those boxes. I'm no C# expert myself, haven't used it for several years (since right before LINQ was introduced) so I'm not sure, but it looked to be along those lines when it was being proposed.