Viewing 15 posts - 7,396 through 7,410 (of 59,098 total)
Sounds good. Looking forward to it.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 9:12 pm
It's also great for the archival of data. Please see "Example B" at the following link.
https://docs.microsoft.com/en-us/sql/t-sql/functions/compress-transact-sql?view=sql-server-ver15
It could also be an easy way to ZIP such data for data transmission...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 8:03 pm
This is a nice narrow table. You can do a lot of what you ask for auto-magically in 2017 using System-Versioned Temporal Tables. It will not only record the history...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 7:51 pm
For my part I really appreciate the deep analysis into components. It's vital to make progress in a good way so I think it's essential research. It NEVER takes...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 7:37 pm
Just one point - not sure it makes a difference in performance but you can avoid this:
@BitBucket = RIGHT('00000000000000'+CONVERT(VARCHAR(14),Col01),14)By using this:
@BitBucket = RIGHT(CONCAT('00000000000000',...--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 7:15 pm
IF the pattern is consistent, this is easy.
--===== Create the test data. This is not a part of the solution.
CREATE TABLE #Temp
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 6:19 pm
>> THIS coming from the person that says he likes the MySQL "standard" of using YYYY-00-00 as the notation for whole years and YYYY-MM-00 for whole months. What a...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 5:10 pm
Lordy, no. That's one of the slowest methods possible. I'll be back to prove it. Just don't use FORMAT!
Jeff, maybe so, maybe so. It appears the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 4:22 pm
From what you've posted, you start off wanting to treat this data element as a string, but then you're storing it as a numeric. You also don't know that...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 2:55 am
"Pfffft! *he* wrote it??? Not reading that!!"
LOL
What I meant was that you posted the correct answer first and I missed that. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 2:34 am
Thanks for the feedback but I'm, actually pretty late with my observation. pietlinden pretty much said in his first post what I was talking about and I simply didn't read...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 12:37 am
p.s. It would be gentlemanly if you posted either the script or the link where you got the script that you claim helped you to identify columnstore indexing candidate tables.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 12:05 am
Please read the following article. They have code to calculate "S" and "U" values that you could programmatically interpret. Combine that with the compression estimator code (documented in Books Online...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 12:03 am
As a thought, do you have a linked server on Server1 that points back to Server1?
Great thought. It could also be a synonym between two servers that's using a...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2020 at 10:02 pm
What I'm waiting for is to find out when you have an employee that owns more than one car. You need a "Bridge Table" that assigns vehicles to owners. And,...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2020 at 9:57 pm
Viewing 15 posts - 7,396 through 7,410 (of 59,098 total)