15. marts 2004 - 10:59Der er
9 kommentarer og 1 løsning
Hvordan fjernes fejlen: time is too far in the future
Hvis man ad vanvare eller på grund af teknisk fejl har kørt en Domino server med en dato som ligger i fremtiden får man følgende fejl fra diverse databaser: time is too far in the future
Denne fejlmelding betyder at man ikke får opdateret diverse views, medmindre man tvinger en opdatering igennem med server konsol kommandoen 'Load Updall -R' eller man i en enkelt view benytter Shift+F9 til at rebuilde et view. Disse kommandoer skal udføres hver gang man ønsker viewet opdateret!
Man kan naturligvis i NAB tvinge UPDALL -R til at køre hver time, der et ret resource krævende. Man kan lave nye replikakopier af alle databaser, så bliver datoen i fremtiden kun kængende som en oprindelig dato - men hvornår vil den så igen begynde at genere.
Jeg har en enkelt server der p.g.a. teknisk fejl på denne måde har stemplet alle databaser med år 2017 - det er meget længe at vente på at tiden læger alle sår ;-)
Replication History bør under alle omstændigheder slettes. Jeg har hørt om fejl med Inbox aflevering og FT-indexer, som ikke kunne rettes med ReplicationHistory. Nogle gange skulle Indbakken fjernes og genopbygges med design refresh.
RE: CORE CLIENT BUG: Database time is too far in the future Posted by Jim Rouleau on 9.Jul.03 at 10:41 using Lotus Notes Category: Notes ClientRelease: 6.0Platform: Windows XP
I asked the appropriate developers about this and here is the response. Hope it helps.
In pre-V6 builds, the worst thing that could happen to a database (besides corruption) is for the system time on the server (or client if database is local) to be set backwards. Many things break like view updates (new documents don't appear and deleted documents are not removed) and replication. These bugs have been next to impossible to track down because there is usually very little evidence that time went backwards (manually or via bugs) once a problem has been detected. In V6 we decided to address the time backwards bugs by not allowing database time (internal time stamps) to go backwards. This means nothing will break if time goes backwards on the machine where the database is located. A side effect of this approach is that some displayed time stamps will be in the future. That is why we display "time is too far in the future" messages. This is an informative message (there is no bug) we generate so that the administrator can take action if they want to. Creating a new replica will fix all time stamps in the database.
Med R6 låser man datoen i basen og det har jeg faktisk godt observeret - man ændrede et designelement og datostemplet blev denne dato i fremtiden.
Når de hos udviklerne fortæller at en ny replika er løsningen, så kan det lade sig gøre - jeg havde bare observeret at man stadig kunne se datoen ud i fremtiden i den nye replika og derfor ville jeg ikke begynde med 30 databaser a 500MB to 20 GB størrelse.
Nu er der en løsning - i mit tilfælde er datoen 24/3 2004 - så i dette tilfælde læger tiden såret.
Jeg accepterer din kommentar som svar, så nu må du lige lægge et svar så du kan få af mine point!
Error: "Time Is Too Far in the Future" Running Fixup on Mail Files After Upgrade to Domino 6.x
Technote
Problem After upgrading to Domino 6.x from R5 and running fixup on the mail files, you receive the error:
"Database (Database Name) time is too far in the future".
Solution In this case, the mail files are part of an R5 server that experienced a time creep issue prior to upgrading the server to Domino 6.x. Documents were created as far into the future as the year 2030. When the Domino 6.x fixup runs on the mail files, many of the folders and documents in those folders are deleted and can only be found in the All Documents view. Since these documents were created so far in the future, they were marked as corrupt and removed by the fixup utility. Fixup is working as designed.
Options to work around the issue:
a. Create a new replica (File\Replication\New Replica) , or b. Create a new copy (File\Database\New Copy), or c. Create a new file and copy information from the old file into the new file.
Start with Option "a" and work down until fixup runs to completion without error.
Nu har jeg så fundet denne Technote - her er en tretrins løsning.
/Hans Holt
Som martinowitch har jeg heller ikke fundet samme løsning som Jogii
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
