@ErikDarling It is a weirdish function. According to the docs, it only detects nesting level of trigger objects: "Returns the number of triggers executed for the statement that fired the trigger.".
"Arguments: object_id - Is the object ID of a trigger. If object_id is specified, the number of times the specified trigger has been executed for the statement is returned."
Well we own the box, so pretty much any date that hasn't been fully claimed yet. I think it holds up to 24 people or so. So usually most dates are open if I request early enough in advance.
E.g. anything that's 2+ weeks out from now is probably available still I'm assuming.
@ErikDarling hah, so many cancellations this season so far. The worst is actually showing up, waiting 2 hours for a delay, and then it being cancelled anyway.
@ErikDarling sounds good, I'll see what I can make happen.
P sure that's the area our box is in, if memory serves me correctly.
@ErikDarling Well, there's some unusual syntax there and you probably want to clear the session context after firing the trigger so that session can call the trigger at other times.
SESSION_CONTEXT returns sql-variant so just convert it, no need for a nested SELECT
a lot of the dynamic sql that i've written has been in analysis scripts that had to run across a lot of older versions of sql server, so i never got in the habit of using it
my habit it most using + convert(nvarchar(max), N'...') + to avoid truncation issues
@J.D. It prevents connection pooling across users for a start. And if you are using it for a public facing web server you don't want to have to create thousands or millions of AD users just to log in to SQL Server. Instead you use other authentication methods to gate access to SQL queries (OAuth etc), and you wouldn't allow direct SQL access anyway, only via the web server.