Reputation
777
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
8 15
Impact
~19k people reached

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 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
Apr
10
revised How can I remove an index scan from a SQL Server SELECT statement?
formatting, English improved
Apr
10
suggested approved edit on How can I remove an index scan from a SQL Server SELECT statement?
Feb
29
awarded  Enthusiast
Feb
22
accepted Save Transaction: Is the name local to the stored procedure or not?
Feb
22
comment Save Transaction: Is the name local to the stored procedure or not?
Right. Yes, that makes sense. The code needs another stare which it will get. But then, it's not that big, and in two days I haven't been able to find any possible way for the control flow to not hit both rollbacks, both by executing it in my head and pressing F11 repeatedly. Either someone is a moron or this needs to be properly reproduced and posted to connect. Thanks for your help.
Feb
22
comment Save Transaction: Is the name local to the stored procedure or not?
That is exactly what I cannot understand. If a rollback was stepped over for some reason, then surely switching to the newid() thing would not help? But it did help, and it's 100% reproducible; if I switch it back to the constant name, it is misbehaving always, and with the random name it is doing the right thing always.
Feb
22
comment Save Transaction: Is the name local to the stored procedure or not?
Ok. That makes sense. They are global and I've learnt that. But why does it work as naively expected in the example? Does the first rollback make it "forget" the savepoint, so that the second rollback rolls back to the previous savepoint of the same name? And if so, how came it didn't happen in production, where number of rollbacks equals number of save trans?
Feb
22
revised Save Transaction: Is the name local to the stored procedure or not?
typo
Feb
22
asked Save Transaction: Is the name local to the stored procedure or not?