| Subject | Re: [IBO] timestamp edit again |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-06-29T22:31:06Z |
Oliver,
At 08:22 AM 29/06/2005 +0000, you wrote:
you understand that a timestamp is not two fields, but one. IBO has the
ability to display only the date part or the time part of a timestamp (see
the NO DATE and NO TIME column attributes) for fields that you store (or
retrieve) as DATE or TIME types. However, the effect of editing a TIME type
is different from editing a DATE or a TIMESTAMP type.
What you seem to want is a mechanism that can interpret changes to a DATE
field and a TIME field and calculate a new timestamp based on the old and
new values of these fields. I can't think of a direct way to do that using
databound controls. You'd have two ways to hook the split timestamp to d/b
controls - either as virtual fields (by retrieving two computed (CAST)
fields from your timestamp) or as calculated fields. In either case,
though these values could be displayed in d/b controls, they are read-only.
One way to make your requirement work is to add the TIME and DATE fields to
your table and write triggers to either split the TIMESTAMP field or merge
the TIME and DATE fields (or both) at the appropriate point. That would
have to be done with extreme care, since you must avoid having intentional
changes to one or another cause unintended updates at trigger time. Also,
the client side has no knowledge of what's going to happen in triggers. If
you wanted the updated timestamp to show in the UI before posting, you
would also need some event code at the client to make that happen, that
would not interfere with what your triggers will do subsequently.
The other way would be to maintain two internal fields in your client app
that you surface in non-bound date/time controls, and perform the necessary
row-level calculations at the client to update the timestamp. Without
knowing your requirements, that's the one I would go for.
Helen
At 08:22 AM 29/06/2005 +0000, you wrote:
>HiI don't know what I missed earlier in this thread -- but I wonder whether
>
>because nobody answered my last question i give it a second try
>
>I would like to use a data-bound edit for a time-stamp. The problem
>with TIB_Date is, that if you select a date from the calendar the time
>portion is lost.
>In addition to that I would prefer two edit fields; one with the date
>and one with the time.
>
>TIB_DateTimePicker doesn´t work with the dtkTime setting.
>
>Is it possible to make a calculated field with the time-portion of the
>Timestamp in that way I could edit the field with this calculated
>field? Or do you have another idea?
>
you understand that a timestamp is not two fields, but one. IBO has the
ability to display only the date part or the time part of a timestamp (see
the NO DATE and NO TIME column attributes) for fields that you store (or
retrieve) as DATE or TIME types. However, the effect of editing a TIME type
is different from editing a DATE or a TIMESTAMP type.
What you seem to want is a mechanism that can interpret changes to a DATE
field and a TIME field and calculate a new timestamp based on the old and
new values of these fields. I can't think of a direct way to do that using
databound controls. You'd have two ways to hook the split timestamp to d/b
controls - either as virtual fields (by retrieving two computed (CAST)
fields from your timestamp) or as calculated fields. In either case,
though these values could be displayed in d/b controls, they are read-only.
One way to make your requirement work is to add the TIME and DATE fields to
your table and write triggers to either split the TIMESTAMP field or merge
the TIME and DATE fields (or both) at the appropriate point. That would
have to be done with extreme care, since you must avoid having intentional
changes to one or another cause unintended updates at trigger time. Also,
the client side has no knowledge of what's going to happen in triggers. If
you wanted the updated timestamp to show in the UI before posting, you
would also need some event code at the client to make that happen, that
would not interfere with what your triggers will do subsequently.
The other way would be to maintain two internal fields in your client app
that you surface in non-bound date/time controls, and perform the necessary
row-level calculations at the client to update the timestamp. Without
knowing your requirements, that's the one I would go for.
Helen