I'm not sure where you're going with that. Like anyone else, more than 99% of what I do or have other people do revolves only around the "core"/"simple" knowledge that we've been speaking of and none of that is "complex".

Ironically, what I do find is that many people actually make things more complex by not knowing the simple core technology, and I do mean simple. For example, how many times have you and I seen people use a While loop to update one table from another one row at a time simply because they don't know the core technology of how to correctly form a much more simple joined UPDATE even at simple ANSI levels? How many times have you and I seen people use complex IF logic in their stored procedures because the don't understand the simple core logic of CASE fuctionality?

Absolutely agreed on that but don't confuse "simple" with coding to the lowest common denominator. That's not the "simple" I'm talking about. But you also don't need to write a CLR to do something "simple" like generating random integers.

Even for non-core knowledge, how hard is it to learn what a BCP format file is to import a fixed-field file usig BULK INSERT? Heh... and don't think for a minute that I have what a BCP format file needs to look like memorized. I have to look it up every time because, like you, I don't have to do it all that often. But that brings us to another "core" technology that's terribly overlooked. It's in "Books Online" and more than half the "developers" that I've interviewed don't even know what that is.

I absolutely agree and I'm always interested in new skills and tools but if you suggest to me (more true examples) that I need a CLR to generate random integers or "universal triggers" or that I need to write a PowerShell script to do centralized backups even for a thousand servers, I'm going to shut that notion down right away.

Shifting gears, it's also a two way street. Lets say that someone comes in with a great idea using a "new" technology (PowerShell!) against the database and I like the idea a whole lot. If I can pull the same thing off in T-SQL using "core" technology or even an "exotic" technique in T-SQL like the Tally Table, why is it that the lecture of "Well, just because you can do something in T-SQL, doesn't mean you should" always seems to rise to the surface? If I'm doing something with the database and I can do it in T-SQL, why shouldn't I? You and I saw this when you and I were having fun with our friendly but very competative (and very enjoyable, I might add) Regex races many years ago.

Then there's the "manager great idea". I won't say what program we bought or what it does but it cost about the same as paying my salary for more than 2 years. It was a great idea except that it cost too much on initial investment, has a very steep learning curve (it took people almost 2 years to get a decent grip on it and they still haven't figured out some of the high profile "gotcha's"), is difficult to use, and even though it has a huge and nasty impact on the SQL Servers, it's scheduled outside of SQL Server where I have absolutely no control over it. It would have been an easy thing to do in SQL Server but, once again, I had to listen to the same tired old saw of "Just because you can do it in SQL Server, doesn't mean you should". This is the type of technology "improvement" that I've seen way to many times and that, given the opportunity, would have summarily shut down, as well.