>on 1/31/04 8:59 PM, Robert Brenstein at rjb .AT. rz .DO.T uni-potsdam.de wrote:
>
>>> on 1/31/04 7:39 PM, Robert Brenstein at rjb@rz.uni-potsdam.de wrote:
>>>
>>>>>> -- option to have automatic time stamping of all or specific fields
>>>>>> in a baseobject (updated only when content changes)
>>>>>
>>>>> Yes, we have add DB.Clocks(), and TIMESTAMP field.
>>>>
>>>> Is the TIMESTAMP an internal field (handled automatically by kernel)
>>>> or it is a field for us to use explicitely? Ideally, a field would
>>>> have a property "timestamp" settable through Field_SetFlag() and then
>>>> we have a call Field_GetTimestamp() to find the current value. It
>>>> should also be properly handled through SQL, so we can easily find
>>>> records with fields that were modified after specific timestamp.
>>>
>>> This is new field type.
>>> Actually it is ULLONG.
>>>
>>> It looks we have not yet polish this field type.
>>
>> So what is the advantage of this new field versus my using a normal
>> long field to store a timestamp? This is what I do now.
>
>It is intended to store INTERNAL DB CLOCKs value.
>
>Probably it will get value automatically
But what will trigger the update? Any change to a record containting
a timestamp field? Or can it be associated with a specific field? In
other words, will the automatic process be associated with SetField
or with UpdateRecord/NewRecord? I gather it will be triggered in
either case by any call, even if the content is not truly changed.
Robert
_______________________________________________
Valentina mailing list
Valentina .AT. lists .DO.T macserve.net
http://lists.macserve.net/mailman/listinfo/valentina
©2004 Robert Brenstein |
