Post reply

GetDate() in blocked sessions

  • January 3, 2017 at 10:50 pm

    #339175

    Comments posted to this topic are about the item GetDate() in blocked sessions

    God is real, unless declared integer.

  • January 3, 2017 at 10:51 pm

    This was removed by the editor as SPAM

  • January 4, 2017 at 12:37 am

    #1920545

    Nice question, Thanks.

    But little confused with the explanation of "Another Interesting Fact":

    when you remove in session 1 the GO between the UPDATE and the WAITFOR (so both commands run in the same batch as they would do, when they are in a procedure), session 2 will not start before the one minute timer passed so the time_col would contain 09:01:00 (after finishing session 1) in this case (even a PRINT GetDate() before the BEGIN TRANSACTION in session 2 would return 09:01:00)

    Why Session 2 will not start before the one minute.?

    Thanks

  • January 4, 2017 at 1:20 am

    #1920547

    The correct answer is "depend" on numbers of records in the table:

    With one or few records the correct answer is "09:00:10", but with many records (in my case 6800) the correct answer is "09:01:00".

    Fill the table with many records:

    create table tbl (col1 varchar(100), time_col datetime)

    insert into tbl select name,getdate() from sys.objects

  • January 4, 2017 at 4:32 am

    #1920567

    Hi,

    In tests that I performed the bit in SQL Server Express SP1 2016 the correct answer was the alternative 9:01 (after finish of session 2).

    Please could you check.

  • January 4, 2017 at 5:40 am

    #1920578

    Blech! I knew the right answer but clicked the wrong option. Goes to prove that jumping too quickly to answer without double-checking can be hazardous!

    LinkedIn: https://www.linkedin.com/in/sqlrv
    Website: https://www.sqlrv.com

  • January 4, 2017 at 9:22 am

    #1920673

    Junior Galvão - MVP (1/4/2017)

    Hi,

    In tests that I performed the bit in SQL Server Express SP1 2016 the correct answer was the alternative 9:01 (after finish of session 2).

    Please could you check.

    Please do not hint at the correct answer in the discussion thread.

  • January 4, 2017 at 9:43 am

    #1920677

    Revenant (1/4/2017)

    Junior Galvão - MVP (1/4/2017)

    Hi,

    In tests that I performed the bit in SQL Server Express SP1 2016 the correct answer was the alternative 9:01 (after finish of session 2).

    Please could you check.

    Please do not hint at the correct answer in the discussion thread.

    Eh, I don't think referencing the answer in the forums is a major concern. You can't get to the forum directly until you answer the question. I suppose you could try and get to the discussion using page caches or connection string spoofing, but why bother when you can just create a second account to answer the question and get the correct answer more directly.

    Besides, it is not like the points are actually worth anything. I think a good informative discussion is much more valuable (at least for me). The cheaters are really only cheating themselves.

  • January 4, 2017 at 11:13 am

    #1920706

    I find it hard to believe you could open a second session and start it at exactly 10 seconds after the first query was executed.

  • January 4, 2017 at 11:19 am

    #1920710

    sestell1 (1/4/2017)

    Revenant (1/4/2017)

    Junior Galvão - MVP (1/4/2017)

    Hi,

    In tests that I performed the bit in SQL Server Express SP1 2016 the correct answer was the alternative 9:01 (after finish of session 2).

    Please could you check.

    Please do not hint at the correct answer in the discussion thread.

    Eh, I don't think referencing the answer in the forums is a major concern. You can't get to the forum directly until you answer the question. I suppose you could try and get to the discussion using page caches or connection string spoofing, but why bother when you can just create a second account to answer the question and get the correct answer more directly.

    Besides, it is not like the points are actually worth anything. I think a good informative discussion is much more valuable (at least for me). The cheaters are really only cheating themselves.

    Well I work in a high-confidence environment where a small violation of IP will likely get you fired on the spot. 🙂

  • January 5, 2017 at 4:34 am

    #1920827

    makes sense, thanks

    - Damian

  • January 5, 2017 at 7:29 am

    #1920873

    Well I got this one wrong. Learned something today. Thanks.

  • January 15, 2017 at 8:19 pm

    #1922852

    The explanation is a bit confusing with that "interesting fact", as it refers to a non-existent "begin transaction" statement in session 2.

    And if removing the GO in session 1 has an effect that causes session 2 to hang before reading the time there is a great big bug somewhere in SQL Server that makes things hang up when they shouldn't.  I guess that ties in with the non-existent begin tran, so that the code has been changed since the "interesting fact" was written and the "interesting fact" didn't get updated to match, as the great big bug doesn't exist.

    Tom

  • February 16, 2017 at 4:12 am

    #1928794

    But if the data table is empty then ?
    updates do nothing?
    Do then the output answer would be?😀

Viewing 14 posts - 1 through 13 (of 13 total)

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