Viewing 15 posts - 6,226 through 6,240 (of 59,072 total)
its 10k partitions according to the OP
Lordy... I wonder if the partitions are "hourly".
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2020 at 5:21 pm
Heh for a lot of folks, they actually did wait until it broke. 😀 Most every one else (that I knew at the time) waited until 1999. I made my...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2020 at 5:19 pm
It also increases the number of characters to be transmitted by a whopping 25% compared with "YYYYMMDD" and it was specified and designed in an age where 110-300...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2020 at 4:04 pm
Lordy... looking at this again, I see partition numbers that exceed 5500 partitions. If you divide 5500 by 365, that's 15 YEARs of days if you've partitioned by day. I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2020 at 3:41 pm
Spot on, Grant. Another thing that the use of variables affects is actually whether or not even properly setup "Minimal Logging" will occur. If you're trying to do Minimally Logged...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2020 at 3:17 pm
To keep the record straight, the ANSI/ISO SQL standards allow only the ISO – 8601 "YYYY-MM-DD" format for dates. The. The reasons we pick this one were:
1) it's not...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 11:28 pm
<headdesk> 😀 Fixed the post.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 3:56 pm
Look for queries which are heavy on BLOB processing.
You mentioned BizTalk - do you have some massive FOR XML queries? It may be either massive XML (JSON, you name...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 4:18 am
Ah... almost forgot. One of the things that MS did very, VERY wrong is how they interpret the (secondary ANSI) format of YYYY-MM-DD when used for direct conversions from strings...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 3:14 am
Ugly, but this works:
DECLARE @SchedStart VARCHAR(25) = '2020-06-07-12.30.00.00000';
SELECT @SchedStart
,CAST(STUFF(STUFF(STUFF(LEFT(@SchedStart, 23), 11, 1, ' '), 14, 1, ':'), 17, 1, ':')...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 12:06 am
Just a different take on the same subject...
If the dates and times always follow the same format, which would also be required when using STUFF, then the hidden ANSI capabilities...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2020 at 12:00 am
Thanks for the correction, Scott. I plumb forgot about that aspect of CHECKs (mostly because I make end-date columns NOT NULL). They're like FK's in that aspect... they don't have...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2020 at 5:26 am
GUIDs are horrendous for clustered indexes. They fragment like crazy.
No sir... that's absolutely NOT correct. In fact, they can go for months without any page splits (not even supposed...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2020 at 5:10 am
Scott? 🙂
Sorry... had a "Scott" on my mind from a different post. Corrected my previous post.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2020 at 6:58 pm
CREATE TABLE Employee_Leave
While I agree that the original table name that the OP posted left some to be desired, so does the one you created. Wouldn't Employee_Leave_Days_Taken be more...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2020 at 6:56 pm
Viewing 15 posts - 6,226 through 6,240 (of 59,072 total)