I don't usually talk about shit that's DBA-material, but this is one of my fav essays about Morality and it's pretty relevant right now. If anyone wants to read it. marxists.org/archive/trotsky/1938/morals/morals.htm
@Philᵀᴹ You can see crap like that on Jobserve on a semi-regular basis. The recruiters know they don't have any hope of placing someone competent but they're obliged to go through the motions.
I'm having issues with getting SSRS to acknowledge an AD group's permissions.. the group members can run queries from Excel, but can't run SSRS reports even though I've set up their role in report manager. anyone has a clue?
Excellent. How is the report data source defined? Does it use pass through authentication or something else? If pass through, does it work for anyone else to this database (so we can eliminate kerberos)?
There are useful views in the report server itself that help with some of this. The rest is going to be error logs on the server hosting the RS process
Yes, it's always bad to make make behavior dependent on pg_trigger_depth()
Maybe I'm a little less averse to blanket statements, but what good could it do? There is no argument I can see as to why you would want such a feature. The primary purpose of a database is to ensure data integrity. And a...
He says "It is not bad to use per se (IMHO). You just need to be aware of implications." — that is true, but the problem is that most folk visiting this site from Google need more of a nudge towards "If your trigger system is this complex. I think you're playing hot potato with a hand grenade in a closet all by yourself, and it doesn't seem likely to end well".
I'm not convinced the question should remain open though — it looks 'primarily opinion based' to me.
but sometimes there are two or more technically good solutions and some or all are useful to everyone so the question is still good. In other cases the real answer is just 'it depends' and that's not really useful to anyone (and might be downright misleading to some, which is why the question is bad
@EvanCarroll the close reason is not "opinion based", it's "primarily opinion based". To me, this indicates the question will be more about opinions than facts. But, yes, there is usually more than one way to skin a cat.
There is always more than one way to skin a cat, and it always comes down to the opinions of the person submitting the answer, judgement of the community, and the opinion of the person who asked the question. "Primarily" doesn't give that one any footing.
okay, progress - I've changed my shared data source to use Windows Authentication and redeployed; if I restrict access to the [DataSources] folder everything works for "normal users", but if I restrict access to the [Datasets] folder then users can't run the report. I'm kinda flabbergasted that I need to allow users to delete shared datasets from SSRS, so that they can run a report that uses a shared dataset.
it's like the datasets folder is ignoring that "normal users" only have Browser+MyReports roles there
@EvanCarroll I think it does, @Max is exactly right. It is not whether an answer contains (or is) opinion, it's whether the question primarily solicits opinion — a lot of questions solicit testable solutions, and yes, sometimes there is more than one testable solution. This is all perfectly obvious to people familiar with SE — and I think you know it too.
It's good. I would not however recommend starting a new business at the end of a year. I paid a few hundred bucks for LegalZoom to get all the paperwork filed and they did. Sort of. Except for all this taxation stuff
Bah. I'm not answering this I'll be here all day. Suffice to say this question be closed because it's badly formed. The title calls for 36 columns, the question itself shows 4. There seems to be 4 million rows. It could depend on all sorts of factors. And you not having made the answer specific to an implementation makes it even more complex. The maximum columns covered in a composite index from Microsoft are 16 prior to SQL Server 2016.
@MaxVernon I don't use Microsoft, my assumption is the right-most answer involves an index predicate WHERE a=0,b=0,c=0,d=0,e=0..z=0. Or, an index over a computed column (or however Microsoft implements their functional-index hack))
Calls for 26*
If you make an index over a WHERE b=0 AND b=0 AND c=0...z=0. I assume a SELECT * FROM foo WHERE a=0 AND b=0 AND b=0 AND c=0...z=0. will use the index and that it'll be the fastest.
@EvanCarroll I think you're missing the point entirely. The question asks "I have a WHERE clause such as a=0 and b=0 and ... z=0, Would I gain any performance if I replaced that condition with a+b+...+z=0?" and then goes on to point out how the OP tested it, and his supposition that the addition variant is faster. That is provably incorrect, as demonstrated. I brought that question up because you were saying that every answer comes down to opinion, however that is clearly, demonstrably false.
Anyway, if you think you can answer the question, either do or do not. It matters not to me if you think my answer is correct or incorrect. It has 47 up-votes, and only a single down-vote, which I think speaks for itself.
Also, per your comment on row counts, my answer is based on a table with 260 million rows.
Perhaps, if there were several billion rows it might make a subtle difference, but I can't see how.
Or are you implying that it might make a difference if there were only 3 rows?
The downvote doesn't come from me, just fyi. I just think your reading of the question and his presentation leaves plenty of area for opinion. For instance, we don't know what he did even never mind his criteria. He claims it was faster? Was it.. I'm unconvinced he's wrong without clarification. Could it have been faster? That would be an implementation detail either way.
less rows may make a difference.
It's a function of the selectivity of the index, if we're presuming an index speed up. Fewer rows, or less selectivity can amplify the cost of index lookup.
If we're going with 0 indexes exist. As is in the question we're doing a sequential scan anyway. And then the question is just how does MS SQL impliment cola+colb, vs cola=0 AND colb=0.
@EvanCarroll clearly. Again, the point is answers to the question would not be opinion-based. There is a correct answer and an incorrect answer. The correct answer to the question, as asked is "no, it's not faster to use addition vs discrete columns". It's not opinion, it's demonstrated fact. Even if my answer is wrong, it can be proven either way, and therefore the question is not opinion-based.
@ypercubeᵀᴹ agreed, of course. But then you can (almost) always create an index that will answer the exact question highly efficiently.
I'm inclined to agree to some degree but this is your reading of his problem in a theoretical and abstract way which is actually irrelevant to the real world, likely an x-y problem, entirely dependent on implementation, and formulated with insufficient details to make an answer useful to him or others. You've shown us something. For which version of MS SQL I'm unsure of, but I'm also not convinced it's what he wanted, or relevant to what he was asking.
I'm not saying any of that is out of the blue or wrong. It's just how DBA.SE goes, but I don't think this question is much better better than any others because you've managed to read it literally, fill in the gaps, and answer in a way that you feel is objective.
I've been meaning to play with Bloom on PG. I'll to refine his question into PostgreSQL and self-answer it with some data on different ways to do this.
