24. juni 2004 - 21:07Der er
7 kommentarer og 1 løsning
Design elementer og dokumenter med modified date år 3031
Jeg har en db hvor de fleste designelementer (pludselig) er dateret år 3031 i last modified, også selvom jeg laver ændringer i dem. Visse dokumenter i db får/har samme dato. Serverens tid er korrekt. Der er kørt load updall db.nsf -r på basen. Umiddelbart volder det ingen problemer, da revisionsdatoer mm. genereres via computede felter på dokumenterne, og ikke via @modified, men noget er der jo galt, så jeg frygter lidt hvad det kan ende i... Nogle løsninger ?
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
Sålænge det er design er det ikke det kritiske problem. Men vær bange for hvis dokumenter bliver rettet med en fremtidig dato. Men jeg kan næsten læse på det du skriver at det er dokumenter og ikke design der er opdateret. Hvad står uret til på din egen maskine? Notes har i nyere versioner indbygget en regel at "las updated" ikke kan tilbagedateres, fordi så sker der "underlige" ting vedr. replikering. Problemet bliver så at replikering faktisk først vil virke engang år 3031 for den pågældende database.
Det er både dokumenter og design. Ikke alle dokumenter, og heller ikke alle designelementer. Og der er ingen sammenhæng imellem hvornår dokumenterne/design elementerne rent faktisk er redigeret sidst. Min egen maskines ur står på "Burde ikke arbejde nu", så det går rigtigt :-) Det er forøvrigt R5 databaser, på en R6 server. Hvis det kun er replikering der kan give problemer, har det ingen praktisk betydning- denne database replikeres ikke. Men dokumentations- og udviklingsmæssigt er det noget skidt ikke at kunne se den korrekte last modified på design elementerne.
Godt tænkt! Hvis jeg copy/paster fra fejlbehæftet database til kopi uden fejl = korrekt dato. Hvis jeg copy/paster fra kopi uden fejl til fejlbehæftet dato = år 3031... Begge copy/paste med udgangspunkt i at copy er fra et designelement oprettet hvorfra copy sker.
Hvis ikke ulæstemarkeringer spiller en rolle for denne database ville jeg skille mig af med den. kopiere alle designelementer over i en ny database, kopiere alle dokumenter, udskifte databaserne på serveren og parkere/arkivere den defekte database som et kuriosum. Evt. sende den til inspektion andetsteds.
joe..da databasen alligevel skal splittes op i flere databaser, eftersom dens brug er blevet udvidet og strukturen dermed ikke holder mere, ville jeg alligevel gøre det du foreslår. Men jeg ville jo vældig godt have en forklaring/løsning på "fænonemet".... (men der er ingen docLinks, det er en db der leverer (under)menupunkter til en (hoved)menu på web, generet af en javaapplet, der får sine input via et lotusscript). Men tak for kommentarerne. Hvis du vil se et ex., kan jeg lægge db op, dersom du vil kigge nærmere på det.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
