Viewing 15 posts - 4,231 through 4,245 (of 59,098 total)
There is no need for the FROM clause in the first example.
I also prefer the second example because it's easy to change it to a SELECT to see what it's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 6:57 pm
ALter PROCEDURE [dbo].[test] @frDate date, @toDate date, @VCode nvarchar(15) = null, @VName nvarchar(100) = null, @CCode nvarchar(15) = null, @CName nvarchar(100) = null, @CGroup nvarchar(15) = null as begin...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 6:37 pm
It's been a looooong time since I've had to ask for sql help...lol. I've added an attachement with some sample data. Sorry about that and thank you for taking...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 6:22 pm
Wouldn't that be related to parameter sniffing in the scenario I gave vs function in a WHERE clause in the OP? And if so, the performance...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 6:19 pm
Yeah! That last part forms a beautiful Type 6 SCD (Slowly Changing Dimension) but it's missing the "who dunnit" column. Adding one will either put the screws to the Temporal...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 6:13 pm
Yes, agree that it would benefit in the read loads. But we should also consider the overhead of CI on write operations. So if the database is read-intensive then...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 5:27 pm
i would not use clustered index is if the table needs to be dropped on occasion and recreated and the clustered index rebuild. This could take forever.
That's a part...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 5:14 pm
This follows the same pattern as a "Catch-All" query and Grant is totally correct... both performance and resource usage, even for a small table, is going to suffer a lot...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 2:08 pm
See the article at the similarly named link in my signature line below for a copy of the dbo.fnTally() function I use in the following. There are 3 main processes...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 4:49 am
You're welcome and thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 1:11 am
Heh... Temporal Tables. Reminds me of String_Split(). Fantastic idea but they left a part out... like who or what made the update. 🙁
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2021 at 11:31 pm
Yep. Totally agreed that the 52/53 week things get folks a whole lot closer than most but, as you say, what do people thing they're actually comparing? Even the almighty...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2021 at 11:24 pm
Thanks for the feedback, especially after a whopping 16 years! 😀
While the code I posted still works, I've developed a real hate for the "wk" date-part. I also normally don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2021 at 10:58 pm
Guess the op lost interest.
It also looks like we've had a problem with DBCC TIMEWARP on this thread. The original post was on 14 Dec 2021 at 11:59PM.
Even the Op's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2021 at 3:46 pm
Hi, I have been looking for the most correct way to handle this kind of analytics (periods) with sql server, and this article has been the closest to get...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2021 at 2:01 pm
Viewing 15 posts - 4,231 through 4,245 (of 59,098 total)