Best Practice to Simulate Time

Hi,
We have the need to roll the time of the database server forward to perform
some time sensitive testing. The problem is that the database test server
is part of a production Windows 2000 environment. I suppose the optimal
thing to do would be to move the clock on the server forward X number of
hours, and then test our procedures. The problem is that Windows 2000 will
automatically sync up the time because of the Kerberos security. We can't
change the time on all of the servers. Also, when our SQL queries are
retrieving the date/time, it calls GetDate().
Does anybody have any ideas of what we could do to simulate time? I know
one quick and easy answer is to set up a completely separate environment
perhaps with one server. We could put Win2k and SQL Server on that box. It
would be its own domain, so we coould play with the time however we want. I
was wondering if there was a better way of doing this.
Thanks in advance,
cj
Pull the server out of domain and see if it works. You may need to
reconfigure the service account
Thanks
Ravi
"Curtis Justus" wrote:

> Hi,
> We have the need to roll the time of the database server forward to perform
> some time sensitive testing. The problem is that the database test server
> is part of a production Windows 2000 environment. I suppose the optimal
> thing to do would be to move the clock on the server forward X number of
> hours, and then test our procedures. The problem is that Windows 2000 will
> automatically sync up the time because of the Kerberos security. We can't
> change the time on all of the servers. Also, when our SQL queries are
> retrieving the date/time, it calls GetDate().
> Does anybody have any ideas of what we could do to simulate time? I know
> one quick and easy answer is to set up a completely separate environment
> perhaps with one server. We could put Win2k and SQL Server on that box. It
> would be its own domain, so we coould play with the time however we want. I
> was wondering if there was a better way of doing this.
> Thanks in advance,
> cj
>
>
|||Firstly and most importantly, why would you even consider doing this kind of
test on a production server?
I generally make it a rule to avoid writing time-sensitive code precisely
because of the obvious testing problems. If you need to reference the
current date and time then parameterize it or make your own class or
function to retrieve the clock information. That way you have a single point
at which you can interpose your own time value for testing purposes.
David Portas
SQL Server MVP
|||Ravi,
That is what I figured I would have to do. Thanks for the confirmation.
Take care,
cj
"Ravi" <Ravi@.discussions.microsoft.com> wrote in message
news:D4301F76-89AD-4554-9B8F-33EE8C686284@.microsoft.com...[vbcol=seagreen]
> Pull the server out of domain and see if it works. You may need to
> reconfigure the service account
> --
> Thanks
> Ravi
>
> "Curtis Justus" wrote:
|||David,
To answer your first question: there aren't any other production databases
on this "production" server. The only reason why I called it a production
server is because it is located in an active domain. They are converting
from a Netware network to the Win2K-based system and are slowly
transitioning over. I'm sorry for not sharing that information.
The date thing was something I had asked our database people about. However
it is too late in the game to change everything.
With that said, do you have any other suggestions? Perhaps going through
our stored procs and replacing GetDate with a call to a UDF might do the
trick.
Thanks,
cj
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:WpKdnYLmt7VwlV7fRVn-rQ@.giganews.com...
> Firstly and most importantly, why would you even consider doing this kind
> of test on a production server?
> I generally make it a rule to avoid writing time-sensitive code precisely
> because of the obvious testing problems. If you need to reference the
> current date and time then parameterize it or make your own class or
> function to retrieve the clock information. That way you have a single
> point at which you can interpose your own time value for testing purposes.
> --
> David Portas
> SQL Server MVP
> --
>
|||"Curtis Justus" <sure@.you.wont.spam.me.org> wrote in
news:uNp4NMSfFHA.2472@.TK2MSFTNGP15.phx.gbl:

> With that said, do you have any other suggestions? Perhaps going
> through our stored procs and replacing GetDate with a call to a UDF
> might do the trick.
Look out for CURRENT_TIMESTAMP as well.
Here's two crazy ideas:
- find or write a utility that traps all calls to the Windows API that get
the current time, returning a strange result. If necessary, have MSSQL.EXE
be spawned by the utility (instead of the normal service start).
- set the timezone offset to several hundred hours.