Timestamps from clients are unreliable. There may be days between them
(that is batteries run down, things get out of kilter, people overclock
their PC's, someone accidently sets their timezone wrong) and then you have
timestamps that make no sense. If all you are doing is looking for a unique
key use sequences, much easier, less fuss. If you are using timestamps as
real timestamps (when things happened) then make sure the server does it.
The function in Java is pretty simple, you are just getting the current time
and want it in a particular format.
Jim
"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message
news:3d2b4d03.29568767_at_ausnews.austin.ibm.com...
> On Tue, 09 Jul 2002 14:30:33 GMT, "Jim Kennedy" <kennedy-family_at_attbi.com>
> wrote:
>
> >You might modify what you propose. Use varchar2 not char and use the
server
> >to put in the timestamp not the client. That way the time is consistent
and
> >not different because each client might have a different time drift. You
> >can use Java in the database to create a function to return the timestamp
in
> >whatever format you want.
> >Jim
> <SNIP>
>
> Since the nature of this field is that it will always be the same number
of
> bytes, I'm not sure I understand what would be gained by making it
VARCHAR2
> instead of CHAR(n). On the other hand, I'm not sure I understand what
would be
> gained by making it CHAR(n) instead of VARCHAR2.
>
> As for writing a TIMESTAMP function, I'd have to find a Java programmer.
I
> don't believe that in this app, the places where timestamp is used, any
time
> diff between one client location and another would matter, but I'll bring
that
> up with the lead programmer. Thanks for the caveat and the tip.
> --
> Ed Stevens
> (Opinions expressed do not necessarily represent those of my employer.)
Received on Tue Jul 09 2002 - 21:47:22 CDT
