It's best to stop using INFORMATION_SCHEMA views.  They can contain inaccuracies (on ownership) and are incomplete now.

Stick to sys.columns and the other MS standard views.

I guessed you would want to sort/order by Item first; if not, you might want to reverse the GROUP BY to Name, Item.

SELECT Item, Name, 
 ...

Heh... while the world insists that...

A bit tricky really, unless you want to take the 90 separate log files approach.

For example, if you set a job to cycle the log every 15 days, then the...

I recommend one simplification to make your SQL coding and maintenance easier: use "*" in the inner query using ROW_NUMBER().  SQL will still only actually retrieve the data that is...

I believe so.  Just use the standard SQL command to add a file(s):

ALTER DATABASE tempdb ADD FILE

( NAME = ..., FILENAME = '...' , SIZE = nnnMB, ... ),

( NAME...

Worked on my SQL 2016 too.

Just to be safe, add the N in front of the second literal:

SELECT 1 WHERE JSON_VALUE( '{"id":"1","name":"me"}' , N'$.id' ) = '1'

As I understand it, if multiple matches are possible, SQL can match any row.  That is, the results are unknown and you should assume they are effectively random.

Similarly, if you...

I think a smallint would suffice for language code.  I can't imagine there being more than 64K languages (including negative values if absolutely necessary).

Typically one would use a bit value setting to reduce space usage.  For example:

languages int NOT NULL

You'd want a separate table with the language code values:

CREATE TABLE #language_codes...

Again, very bad idea trying to combine all three actions, even for one table, let alone for all tables.

It's easy enough to generate individual procs.  If you wanted to, you...

Typically one would use a bit value setting to reduce space usage.  For example:

languages int NOT NULL

You'd want a separate table with the language code values:

CREATE TABLE #language_codes ( language_bit...

I suppose you could force that to work, but it's a bad idea.  Individual tables have vastly different columns and requirements.

The major problem with your first query is that it doesn't satisfy the original conditions to: select all rows if the value is NULL.  Other than dynamic SQL, the scan...

Of course bad triggers can be written.  Bad stored procedures can also be written, but that doesn't mean we should quit writing stored procedures (agreed?).   Yes, take great care to...