|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Best Practice to Simulate TimeWe 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 -- Show quoteThanks 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 > > > Ravi,
That is what I figured I would have to do. Thanks for the confirmation. Take care, cj Show quote "Ravi" <R***@discussions.microsoft.com> wrote in message news:D4301F76-89AD-4554-9B8F-33EE8C686284@microsoft.com... > 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 -- 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 Show quote "David Portas" <REMOVE_BEFORE_REPLYING_dpor***@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 Look out for CURRENT_TIMESTAMP as well.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. 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.  |
|||||||||||||||||||||||
Other interesting topics