Are the posted questions getting worse?

  • Steve Jones - SSC Editor wrote:

     I don't know how many people need the precision Jeff sees issues with. I think most people just need dates and are glad we have that type.

     

    Indeed I literally had the first legitimate use case in 20 years that actually required more precision than just a datetime would give and needed a datetime2.

  • Steve Jones - SSC Editor wrote:

    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 since SQL Server 7.0 and it stopped working correctly in 2016.  What else is wrong with it that we don't know about because of such "silent failures"?  And would tolerate this for 2 decimal place currency values?

    The bottom line is that, once again, they broke something that used to work just fine.  They're motto seems have become "If it ain't broke, fix it 'til it is".  It's like the changes they made to TempDB in 2016... it broke some serious stuff for people like me because of another fault that they didn't fix.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden wrote:

    Steve Jones - SSC Editor wrote:

    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 since SQL Server 7.0 and it stopped working correctly in 2016.  What else is wrong with it that we don't know about because of such "silent failures"?  And would tolerate this for 2 decimal place currency values?

    The bottom line is that, once again, they broke something that used to work just fine.  They're motto seems have become "If it ain't broke, fix it 'til it is".  It's like the changes they made to TempDB in 2016... it broke some serious stuff for people like me because of another fault that they didn't fix.

    Wow Jeff 😮 don’t stop there. Get that soap box a bit higher 😳

    Just kidding ‘ol friend, just love your posts 🤪

    Far away is close at hand in the images of elsewhere.
    Anon.

  • David Burrows wrote:

    Jeff Moden wrote:

    Steve Jones - SSC Editor wrote:

    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 since SQL Server 7.0 and it stopped working correctly in 2016.  What else is wrong with it that we don't know about because of such "silent failures"?  And would tolerate this for 2 decimal place currency values?

    The bottom line is that, once again, they broke something that used to work just fine.  They're motto seems have become "If it ain't broke, fix it 'til it is".  It's like the changes they made to TempDB in 2016... it broke some serious stuff for people like me because of another fault that they didn't fix.

    Wow Jeff 😮 don’t stop there. Get that soap box a bit higher 😳

    Just kidding ‘ol friend, just love your posts 🤪

    With the performance horrors that 2022 brought upon us for the price of $7K per core, I wonder if PostGreSQL has these kinds of problems?  😉 😉 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden wrote:

    The bottom line is that, once again, they broke something that used to work just fine.  They're motto seems have become "If it ain't broke, fix it 'til it is".  It's like the changes they made to TempDB in 2016... it broke some serious stuff for people like me because of another fault that they didn't fix.

    What I know is that the rounding rules in the DATEPART handling changed in 2016, that is the main problem!

    😎

    The logic is not clear, if you add a millisecond, it may or may not have the desired value....

    This table shows milliseconds added to a datetime value, how those vales are reported in both versions and what the datepart function brings back.

    MSADDED DATETIME120             DATETIME160              MSEC120 MSEC160
    1 2024-11-13 15:15:50.000 2024-11-13 15:15:50.000 0 0
    2 2024-11-13 15:15:50.003 2024-11-13 15:15:50.003 3000 3333
    3 2024-11-13 15:15:50.003 2024-11-13 15:15:50.003 3000 3333
    4 2024-11-13 15:15:50.003 2024-11-13 15:15:50.003 3000 3333
    5 2024-11-13 15:15:50.007 2024-11-13 15:15:50.007 7000 6666
    6 2024-11-13 15:15:50.007 2024-11-13 15:15:50.007 7000 6666
    7 2024-11-13 15:15:50.007 2024-11-13 15:15:50.007 7000 6666
    8 2024-11-13 15:15:50.007 2024-11-13 15:15:50.007 7000 6666
    9 2024-11-13 15:15:50.010 2024-11-13 15:15:50.010 10000 10000
    10 2024-11-13 15:15:50.010 2024-11-13 15:15:50.010 10000 10000
    11 2024-11-13 15:15:50.010 2024-11-13 15:15:50.010 10000 10000
    12 2024-11-13 15:15:50.013 2024-11-13 15:15:50.013 13000 13333
    13 2024-11-13 15:15:50.013 2024-11-13 15:15:50.013 13000 13333
    14 2024-11-13 15:15:50.013 2024-11-13 15:15:50.013 13000 13333
    15 2024-11-13 15:15:50.017 2024-11-13 15:15:50.017 17000 16666
    16 2024-11-13 15:15:50.017 2024-11-13 15:15:50.017 17000 16666
    17 2024-11-13 15:15:50.017 2024-11-13 15:15:50.017 17000 16666
    18 2024-11-13 15:15:50.017 2024-11-13 15:15:50.017 17000 16666
    19 2024-11-13 15:15:50.020 2024-11-13 15:15:50.020 20000 20000
    20 2024-11-13 15:15:50.020 2024-11-13 15:15:50.020 20000 20000
    21 2024-11-13 15:15:50.020 2024-11-13 15:15:50.020 20000 20000
    22 2024-11-13 15:15:50.023 2024-11-13 15:15:50.023 23000 23333
    23 2024-11-13 15:15:50.023 2024-11-13 15:15:50.023 23000 23333
    24 2024-11-13 15:15:50.023 2024-11-13 15:15:50.023 23000 23333
    25 2024-11-13 15:15:50.027 2024-11-13 15:15:50.027 27000 26666
  • Wondering if anyone has time to point me to resources regarding this particular question: Microsoft Recommendations for Update Stats? – SQLServerCentral Forums?

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Viewing 6 posts - 66,706 through 66,710 (of 66,710 total)

You must be logged in to reply to this topic. Login to reply