Change intrinsic function GETDATE()

  • Hi,

    To avoid changing over 100,000 lines of code I need to change the getdate() function itself within SQL server. Can someone please point me in the right direction as to where I can access the code for it. Thanks!

  • I don't think there is a way to do that. It is a system function where MS does not provide the code. You could write your own UDF and place it in master. Then you can find and replace GetDate() with the name of your UDF.

  • brekher (3/7/2008)


    Hi,

    To avoid changing over 100,000 lines of code I need to change the getdate() function itself within SQL server. Can someone please point me in the right direction as to where I can access the code for it. Thanks!

    Now...I've just GOT to ask...

    WHY?????????

    What is getdate() doing wrong? Really - I'm curious (nothing else).

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Hi,

    Thats what I also thought but am trying to avoid the global replace. I did find the code attached in the .txt file. Just started going through it to see if it would work.

  • Its not doing anything wrong. Its just used in too many places and in one environment I need it return a different date and want to be able to modify it if needed without going through the code becuase it would be changed quite often for this specific environment for testing purposes.

  • Let's just say that messing with getdate() will likely get all sorts of system functions/views to start falling apart. If nothing else - this might be your time to go through and put in a "wrapper" function which can then usurp it in all of your user code. But - messing with the actual getdate() function would do it in every circumstance (also not what you wanted since you wanted to be able to modify it at will).

    there are several hundred SSP's using that function. don't mess with it if you value your SQL Server. Really.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Hi,

    On the server that I would change it on, I would want all system views procs, etc.. to see the date returned. Thats why I am looking into changing the function because it was detrmined to be the only solution for the process that needs to be implemented by development. They want to be able to change it at will as opposed to them changing the system time now on the actual server.

  • Also, were you able to look at the file I attached earlier? Would that be a place for to start because I definitly dont want to introduce some sort of home grown code into the system:)

  • You can't change getdate(), so you need to come up with a different plan.

  • brekher (3/7/2008)


    Hi,

    On the server that I would change it on, I would want all system views procs, etc.. to see the date returned. Thats why I am looking into changing the function because it was detrmined to be the only solution for the process that needs to be implemented by development. They want to be able to change it at will as opposed to them changing the system time now on the actual server.

    Then the only place to do this is the system time itself. Even if you could - you wouldn't want to be messing with getDate(). It will result in something unstable and (very likely) completely not supported.

    If you want to emulate the system time being changed, then change the system time.

    I understand you're not sharing your reasons for wanting to do this - but with the info we have right now - this is a bad, bad idea.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Hi,

    My reason is pretty simple, its customer related. We have customers that buy our software and input data-lets say today 3/7/2007. In that case the getdate() is todays date. However, while they are testing and in order to verify that the software is working properly they need to "time-travel" like 6 months and then maybe 1 year ahead and see the data at that time and how renewals, extenstions are processed. Up until now, we have had our network team change the system time but then things like antivirus and other software goes crazy and it takes about 15 min or so for the box and server to be 100% functional again.

  • I'm with Matt, BAD IDEA. It may be better to build test procedures and scripts that will emulate the move to the future for testing purposes. Probably a lot of work, but I'd hate to have to explai why a server died because of changing (or trying to change) an implicit system function.

    😎

  • Then try this one on for size: look at using VM's.

    The host machine and the VM sessions it runs are not at all required to be "in synch" time-wise. you can then fire up a separate VM session for your customer demo - with no virus scanning, etc..., and let them change the VM's system time (which without the PITA softwares that give you trouble should be just about instantaneous).

    when you're done - dispose of the VM (as in - throw it away).

    No fuss, no muss. No messing with your server's synchrony either.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Geez, Matt, I wish I'd thought of using VM's! That is a perfect use of VM technology! Three cheers and virtual pint for Matt!

    :w00t:

    😎

  • Lynn Pettis (3/7/2008)


    Geez, Matt, I wish I'd thought of using VM's! That is a perfect use of VM technology! Three cheers and virtual pint for Matt!

    :w00t:

    😎

    The only bad news through (after the second pass) - licensing. But still - should make things much cleaner.

    thanks Lynn!

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Viewing 15 posts - 1 through 15 (of 17 total)

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