Archives of the TeradataForum

Message Posted: Fri, 01 Sep 2006 @ 18:40:39 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Dieter,

You are correct that the timestamp(6) is overkill.

We could actually use timestamp(3) however, trailing 3 digits are concatenated as zeroes. I think for possible uniqueness workarounds. But I'm not sure.

I agree that this is equivalent :

     Cast((cast tstamp1 as char(19)) as timestamp(0))
     BETWEEN  Cast((cast tstamp2 as char(19)) as timestamp(0))
               AND Cast((cast tstamp3 as char(19)) as xxx

BUT... it gives me the same error :(

The reason for formatting to CHAR(19) is for truncating the precision. Killing the milliseconds.

I tried to directly cast to Timestamp(0) from the tstamp1 field(which is timestamp(6)).

Same Error again...

And I tried to use cast (Current_time as timestamp(6)) even though the TYPE of current_time is TIME(0) WITH TIME ZONE ,just to see if it was a data length issue with odbc.

To my surprise the same type of operation worked.

I didn't quite understand your last statement

"It's usually preventing those Time/Timestamp related problems with ODBC. But of course you still have to check your queries..."

Did you mean that people change to AIA or AAA, AII to get away from these issues?

I would agree, but I am concerned with having adverse effects by changing to Ansi (date math or similar things)

Any thoughts or experience with changing to ANSI mode?

I'm glad this is becoming an interesting discussion!!!

Regards,

Eric Barner.

	<Prev	Next>		<<First	<Prev	Next>	Last>>