Reputation
542
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
1 6 16
Impact
~37k people reached

  • 0 posts edited
  • 2 helpful flags
  • 23 votes cast
Sep
1
accepted Is REPEATABLE READ the right choice for validation before modifying data?
Sep
1
revised Is REPEATABLE READ the right choice for validation before modifying data?
added 30 characters in body
Sep
1
asked Is REPEATABLE READ the right choice for validation before modifying data?
Sep
1
accepted Is there a performance difference in committing and rolling back a read-only transaction?
Sep
1
comment Is there a performance difference in committing and rolling back a read-only transaction?
@AaronBertrand that's fair enough, thank you.
Sep
1
revised Is there a performance difference in committing and rolling back a read-only transaction?
deleted 10 characters in body
Sep
1
asked Is there a performance difference in committing and rolling back a read-only transaction?
Aug
26
comment zero-or-one to zero-or-one
Thank you for contributing, I've considered that approach too. I decided against it in the end because sequence is awkward to implement in sql2008 and more trouble than I'd willing to put up with.
Aug
24
accepted How to avoid a “duplicate key” error?
Aug
21
revised How to avoid a “duplicate key” error?
edited title
Aug
20
accepted zero-or-one to zero-or-one
Aug
20
comment zero-or-one to zero-or-one
You are right in that I gave a simplified version. Of course both Task and Hazard objects are more complex than described and have a slew of their own unique properties. Thus, having them in one table unfortunately won't work for me, but thank you for the suggestion!
Aug
20
comment How to avoid a “duplicate key” error?
@JustinCave, that might work, feel free to post as an answer, any sample code how to re-try would be appreciated. Do you think that catching the error and retrying is the best approach? I do not find it in the wild often.
Aug
20
revised How to avoid a “duplicate key” error?
added 621 characters in body
Aug
20
revised How to avoid a “duplicate key” error?
deleted 47 characters in body
Aug
20
revised How to avoid a “duplicate key” error?
deleted 10 characters in body
Aug
20
asked How to avoid a “duplicate key” error?
Aug
20
comment zero-or-one to zero-or-one
@AndriyM, nope that was not my line of thoughts. I was simply wondering about the most natural way of doing this, and that's what came to mind.
Aug
20
comment zero-or-one to zero-or-one
@AndriyM yep, realize this. It appears that if I simply remove TaskId column from Hazard table completely that would work though. The schema will become asymmetric, regarding the two tables, but as far as I can see will satisfy the requirement. (with the filtered index in-place.)
Aug
20
comment zero-or-one to zero-or-one
@AndriyM It looks like the filtered unique indices will solve it. In the absence of the indices task1 can reference hazard1. (task.hazardid = hazard.hazardid) and task 2 also can reference hazard1. This needs to be avoided. moreover it is possible that task1 references hazard1 but hazard1 references task2 (hazard.taskid = task.taskid). That's also to be avoided. Does this make it more understandable?