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...

Don't use functions in a WHERE clause if you can avoid it, as they destroy "sargability".

In this case, just directly check each variable for NULL or a match, as below. ...

An AFTER UPDATE trigger on the table would capture who, at least as well as you can within SQL Server.  You can use "UPDATE(column_name)" to limit it to only processing...

If the AccountNumber must be changed, it will have to change whether it's the clustering key, and/or a PK, or not.

In that situation, you'd temporarily disable FK checking as needed...

You'd need to post the actual code that processes the cursor for us to really accurately help.

But, likely an extra FETCH is being issued.  People insist on coding multiple FETCH...

No, ID is absolutely not needed.  It's likely to hinder processing since people tend to inevitably cluster on it.

Use the AccountNumber as the clustering key and the primary key.  You...