Viewing 15 posts - 9,211 through 9,225 (of 59,091 total)
Jeff, Yes I didn't explain the requirements as well as I could have.
Nah... you did fine. It was just a little different and the year's worth of month...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 10:09 pm
Thanks to everyone who helped with this. I'm just working through them to understand how each one works. Regards, Simon
Not trying to being a snot on this but most...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 3:10 pm
Thanks for the feedback, Simon.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 3:08 pm
Finding this a bit amusing, "The criteria is that if the 1st of the Month is a Monday then use that Date otherwise use the last Monday of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 3:07 pm
How nice it is to see this again - a bunch of folks working the hell out of a problem to come up with their solutions, each one faster...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 2:55 pm
How nice it is to see this again - a bunch of folks working the hell out of a problem to come up with their solutions, each one...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2019 at 2:53 pm
Talking with the current company lawyers might be the best thing to do. Of course you'd have to get it in writing but you never know... they might just say...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 7:09 pm
This should do, short and simple 😉 😎
USE TEEST;
GO
SET NOCOUNT ON;
GO
DECLARE @MYDATE DATE = '20190101';
;WITH TDATES AS
(
SELECT DATEFROMPARTS(
DATEPART(YEAR,@MYDATE)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 5:41 pm
Also, I missed the final post by Des Norton. Tested that in the same manner as I did previously and his code also also seems to work correctly.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 1:25 pm
Heh... that's what you get for posting PowerShell on an SQL Forum. 😀 😀 😀
The problem is very likely the use of both carriage return and line feed (newline) from...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 6:27 am
Provided that they're not too long, you could use "Extended Properties" (in SQL Server, anyway) to keep track of things. Another method would be to actually store certain documentation in...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 6:21 am
Whew! Still checking but the same August 1954 output from the function I built lists things as the OP requested.

So does September 1954...
--Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
June 1, 2019 at 5:39 am
Ah... crud. Sorry... I have to take back what I said about Chris' code. I noticed that he was using a DATEADD of 27 days in the final result and...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 5:18 am
Shifting gears, I expanded the test dates on Chris' good code and it seems to handle the "leading" edge cases in the places I looked. He also did it in...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 4:45 am
p.s.
Here's what the output looks like. The highlighted row is the "leading" edge case that I spoke of in my previous post. As you can see below, the function I...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 1, 2019 at 4:33 am
Viewing 15 posts - 9,211 through 9,225 (of 59,091 total)