Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Wed 25 Mar 2020

From REST to Notes db in two seconds



Thu 19 Mar 2020

Mind the Gap - A mid-level development manifesto



Thu 19 Mar 2020

High value methods: AppendFieldsWithJSON


March, 2020
SMTWTFS
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

Search the weblog





























Genii Weblog

Tip: Changing "@Created" time

Tue 23 Mar 2004, 03:02 PM



by Ben Langhinrichs
There was an interesting interchange in the R4&5 Gold forum today about setting the date which a document reports with @Created.  Rod Whiteley suggests changing the part of the UNID which represents the date and time, which will work, but has some major drawbacks, such as breaking links to the document, orphaning responses to the document, etc.  Sometimes it is better to stay inside the box.  A better approach is to set the $Created field with a timedate, which will change what Notes uses for @Created and the NotesDocument.Created property.  It is still possible to find the original document creation date by looking at the document properties, which seem to use the UNID, but this will fix replication problems and issues where the @Modified is earlier than @Create.

The $Created field does not seem to be documented in the Help files, but it is documented in the C API header files in STDNAME.H, where it says:

/* Created date, if specified overrides UNID created date for @Created */
#define   FIELD_CREATED   "$Created"

So, if you are experiencing trouble because your @Created is incorrect, you can create an agent such as:

FIELD $Created := @Modified;
""

and run it on the selected documents.  Voila!

Copyright 2004 Genii Software Ltd.

What has been said:


132.1. Tom
(08-03-2007 05:05)

I'm curious how this event can occur (@Created AFTER @Modified).

Can someone explain how you can get documents that have this situation?

Only thing I can think of is replication with servers that have a different (incorrect) time at the OS level.


132.2. Ben Langhinrichs
(03/08/2007 05:28 AM)

That is probably the most likely issue. Soehow, there needs to be two servers set with different date/times.