Ben Langhinrichs

Photograph of Ben Langhinrichs

IBM Champion logo

E-mail address - Ben Langhinrichs







Recent posts

Wed 13 Feb 2019

@MQRY and on-the-fly data retrieval



Mon 11 Feb 2019

Formula language in a JavaScript world: JSON db lookups



Thu 7 Feb 2019

Could working with rich text really be RESTful?


April, 2019
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

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:


136.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.


136.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.