Viewing 15 posts - 346 through 360 (of 59,099 total)
Thanks a lot. That works.
Just to be sure, do you understand WHY it works?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2024 at 5:33 pm
I don't know how many people need the precision Jeff sees issues with.
People seem to be missing the point here. The simple fact is that it...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2024 at 2:25 am
I don't know how many people need the precision Jeff sees issues with.
People seem to be missing the point here. The simple fact is that it worked properly...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 11:11 pm
issue resolved.
It's a two way street... It would have been nice if you'd done like Grant suggested.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 5:16 pm
Yes so I went with 2 queries. Just because it's possible to jimmy horn different sets in the WHERE clause doesn't mean it's a good idea
It's frequently referred to...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 5:05 pm
He he, 2022-07-03 13:41:52.0070000 is now unequal to 2022-07-03 13:41:52.007 depending on the data type 😉 😎
Show your code, ol' friend, so that people don't just look at the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 4:50 pm
Yep... I'm well aware of the default precision for DATETIME2 being 7. That's the whole thing... I'm writing code to check for proper conversions from DATETIME2 (default of 7 for...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 4:44 pm
I cannot sufficiently nor politely express the growing level of disgust I've developed about Microsoft and SQL Server, especially since 2012 sp3.
I'd written some simple code to determine a difference...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2024 at 3:42 am
Mainting non sequential leading key having indexes at a lower fragmentation seems to have, by empirical evidence, kept regression issues at bay.
Have you tried rebuilding statistics instead of indexes?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2024 at 4:24 pm
This is a nicely written article, Phil. Thanks for taking the time to write it.
There are a few "gotcha's" because other people have published the same information for a very...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2024 at 1:30 am
If you look at the column headers of the file and compare them to the table, they don't match. We can't see your package to know what the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2024 at 8:21 pm
Bumping the post so that the post above shows up on the next page. This has been a long standing fault on this forum. I sure hope the get around...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2024 at 8:19 pm
If you look at the column headers of the file and compare them to the table, they don't match. We can't see your package to know what the mapping is. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2024 at 2:35 pm
To be honest, you're probably wasting your time doing traditional index maintenance. Worse yet, you could actually be perpetuating fragmentation if you're using REORGANIZE.
With the thought that I named the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2024 at 2:03 am
If YOUR data center isn't "on the cloud", the On-Prem shouldn't be too different. Normally, "on-prem" is another way of saying that the "data center" is not only owned by...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 7, 2024 at 1:51 am
Viewing 15 posts - 346 through 360 (of 59,099 total)