Viewing 15 posts - 2,296 through 2,310 (of 59,098 total)
Thank you.
I tweaked it a little and implemented this for my case and it worked.
Can you post your "tweaked" code? Others may learn from it.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2022 at 7:02 am
I agree... since NULL is not "nothing" nor even equal to another NULL, I don't know why they made it evaluate for NULL behind the scenes at all or why...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 7:44 pm
As expected!!!! On my desk it takes only 14 seconds to process 131,000 rows. Hardly not a statement that will be executed several times every minute or several times...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 6:32 pm
The problem is documented (well, kind of) in the Microsoft Documentation. They "cop" out on explaining exactly what could happen by "only" saying that having a NULL in the object...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:42 pm
I'll also tell you to never just up and delete a table. Instead, rename it and see if the proverbial phone rings. The job you save will be your own.
After...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 4:47 pm
@carsten.saastamoinen
That "split" contains an incremental recursive CTE and it's going to be absolutely terrible for performance. See here...
https://www.sqlservercentral.com/articles/hidden-rbar-counting-with-recursive-ctes
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 4:43 pm
Wow these are awesome replies and super helpful thank you both so much. It has existed for some time but it stored encrypted data then uses a decryptkey with...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 4:33 pm
How deep does identical data occur from the left side of the VARBINARY(MAX)? You might be able to speed things up a bit by sorting, say, only the left 50...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:52 am
How to convert long data to wide data in SQL without using hard coding?
Regards
Like I suggested on the other thread, Manish, open a separate thread for your own question.
[EDIT]...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:47 am
Correct, you convert the local time to UTC then perform the conversion to Unix timestamp.
In fact, the numeric timestamp is only UTC by convention. There is nothing inherent in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:36 am
Have a doubt regarding converting long data to wide data in SQL with out using hard coding?
Regards
Manish Bose
You should open your own post, Manish, so that it doesn't "get...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:17 am
Back in the '90's at work, I had to have a reel to reel tape reader, a CD reader, a special optical reader, and multiple floppy drives, and a special...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 5:12 am
"It Depends" on what you're talking about. If you're on Eastern Time and you want the correct data based on a UNIX timestamp, then you need to convert your local...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 4:47 am
I am not even sure what your function is trying to do here - or why you would even care about UTC. The UNIX timestamp is an offset in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 2:47 am
The new STRING_SPLIT with the 3rd operand is great for this. The old STRING_SPLIT without it is not. Even MS has stated that the order of the output is NOT...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2022 at 9:27 pm
Viewing 15 posts - 2,296 through 2,310 (of 59,098 total)