Viewing 15 posts - 7,381 through 7,395 (of 59,091 total)
Hi Jeff, The second code option works exactly as I need it. I Saw Bill's first which also works so I marked that as the answer but wanted to...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 6:10 pm
THANKS!
Question: can there be any reason that an error will be thrown while attempting to compress the table? Like what should be 'wrong' with table to cause the compression...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 3:58 pm
Thank you for your feedback, appreciate your valuable time, skills and know ledges. Do you agree if we have more than 5 millions rows in source table, we...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 3:37 pm
Here's the test data using the "old fashioned" way that works in all versions of SQL Server since at least 6.5.
--===== Create the test table from what...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 3:28 pm
Is it really SQL 7, 2000 you are using?
@tpd1989 ,
This is the KEY question on this thread. Please confirm that you are actually using SQL 7 or 2000 or...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 2:38 pm
Neither CROSS APPLY nor the multiline version of VALUES is available in 7/2000.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 2:33 pm
THANKS!
Question: can there be any reason that an error will be thrown while attempting to compress the table? Like what should be 'wrong' with table to cause the compression...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2020 at 1:07 pm
We might even be able to save those 4 extra characters - depending on the source data. If we know for sure that we have a minimum length of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2020 at 9:38 pm
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
Viewing 15 posts - 7,381 through 7,395 (of 59,091 total)