Viewing 15 posts - 2,296 through 2,310 (of 59,099 total)
For me, it's very much something that MS got wrong. They're even trying to make it so that the NULL settings are not optional and Front-Enders are ready to march...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2022 at 9:28 pm
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
Viewing 15 posts - 2,296 through 2,310 (of 59,099 total)