707 reputation
410
bio website
location
age 31
visits member for 2 years, 4 months
seen Mar 24 at 13:26
sql must be lowercase.

May
13
awarded  Caucus
Mar
27
answered How long does it take to do RESTORE WITH NORECOVERY
Dec
21
comment Inline table-valued function vs inline sql
the overall shape is quite different -- please be more specific here.
Dec
19
awarded  Yearling
Oct
31
comment SQL Server 2008 Performance issue with very strange resolution
> In order to find out what is running or going on, I have to run a batch--which makes the problem stop. SO the act of trying to observe the issue resolves it.
Sep
21
awarded  Custodian
Sep
6
accepted CATCH block is triggered when it should not
Sep
6
comment CATCH block is triggered when it should not
@AlexKuznetsov Ultimately, errors that client must see are passed to the client. But there are errors that require internal work. Passing them to the client would imply relying on the client to do that work, and that breaks the incapsulation. The database is not an exclusive data storage only used by one application. Many types of clients can connect.
Sep
6
comment CATCH block is triggered when it should not
Makes sense to me. The context of a try block erroneously survives, so the error functions can return their values, and another consequence would be that an error brings execution into the handler of the erroneously survived try context.
Sep
6
comment CATCH block is triggered when it should not
@gbn Are you saying this is a bug in 2008 that has been fixed in 2012? Is there an entry on connect?
Sep
6
comment CATCH block is triggered when it should not
@gbn When specifically applied to transactions, yes, it does (the template is going to be a bit more complex though, as we have sort-of-okay errors that give XACT_STATE() = 1, so we rollback to a save point and carry on). But I'm more concerned about the very principle of error handling here, even when to transactions are present. Any code after commit_and_exit: is going to execute twice.
Sep
6
reviewed Reject suggested edit on CATCH block is triggered when it should not
Sep
6
asked CATCH block is triggered when it should not
May
7
accepted Associate a piece of data with a session
May
7
comment Associate a piece of data with a session
I'm happy with a separate table as long as I can clearly tell apart live data from expired data. SPID is not really good because it is reused, but if it is only used for nightly cleaning and not for fetching data, then it's going to be fine.
May
7
comment Associate a piece of data with a session
I thought about that, but then we're back to the problem of cleaning up expired data? No wait, we're not. The data will not delete itself, but will not get used by any subsequent connections... Yes, that's an option.
May
7
comment Associate a piece of data with a session
@NickChammas Storing some information about the current user (beyond what is provided by SQL Server directly); mostly for logging, with a little bit of decision making. Not related to security.
May
7
comment Associate a piece of data with a session
What I meant is that there is a restriction on what can be stored as context info. 128 bytes of binary data is enough for me currently, but if I suddenly want a bit more data, it won't fit there, which is "not easily extendable." Switching the whole thing to a different mechanism will then be a pain. You suggestion is the best so far though.
May
7
comment Associate a piece of data with a session
I was just reading about that one when you posted the answer; Possible, but same notes apply as for app_name().
May
7
asked Associate a piece of data with a session