Viewing 15 posts - 4,216 through 4,230 (of 59,087 total)
You have to understand... I don't actually care what the question was. This isn't stack overflow. I was teaching about the proper forms and you don't need a FROM clause...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 8:39 pm
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 8:11 pm
Thank you for the help....
Here is what I finally came up with
DECLARE @startDate DATETIME;
DECLARE @endDate DATETIME;
--DECLARE @dateDiff INT;
SET @startDate = '2018-08-12';
SET @endDate = '2018-08-14';
SELECT TOP 10 [Last Name] AS...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 7:22 pm
There's also something crazy going on with this forum. The timestamp on the original post is for today at 8:15 PM, which hasn't happened here yet. I thought these things...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2021 at 7:01 pm
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
Viewing 15 posts - 4,216 through 4,230 (of 59,087 total)