At 12:08 29/3/2006, Bram Kuijvenhoven wrote:
(deleted text)
low platform and upload the sources, compile, catalog and run
applications on mainframe without new tests. More over it must be
thousands of other applications that would benefit of DB2 TIMESTAMP
format. BTW, the format of TIMESTAMP in DB2 is YYYY-MM-DD
HH.MM.SS.UUUUUU. IMHO, any other format seems to be not correct for
DB2 approach.
This sounds quite obscure to me; are those timestamps used as /unique/ keys?
I never see they used as unique, but as a second column in a discret
key. An example that I can remember now would be keep various
questions done to a call center by the same user/customer...
It would require some investigation to find out whether it is
possible at all to do this. In the first place it would require a
TTimeStamp implementation. Secondly, the ODBC driver should be
capable of passing information about the precision of the timestamp.
Thirdly, the TTimeStamp implementation would be required to support
this precision information as well. Finally, it should somehow be
possible to present the TTimeStamp in the YYYY-MM-DD HH.MM.SS.UUUUUU
format in the GUI controls you use.
A question guys: Why you don't treat TIMESTAMP as a string [26] in
Lazarus? The ODBCConnection must be prepared to treat when write to
table and when transfering from table to program. In cobol this DB2
type is treated in this way and there are thousands(millions) of
programs running OK around the world(although I hate it, it seems
that cobol will never die).
I will take a look at the capabilities of ODBC to pass precision or
format information of columns/data types.
I'm open for any suggestions.
I gave you mine suggestion above
If I'm proposing things that are not possible to implement, please excuse me.
[ ]
Ricardo
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
