Archives of the TeradataForum
Message Posted: Wed, 21 Jul 1999 @ 16:41:02 GMT
I had NCR search their known problems and they did find an incident where this was reported to NCR.
The specific issue was that this format worked in mload at V2R2:
:IN_A_DATE (FORMAT 'YYYY-MM-DD')
but at V2R3, this fails with error:
3617: FORMAT 'YYYY-MM-DD' does not match the datatype.
The resolution is to add the DATE data type in front of the format:
:IN_A_DATE (DATE,FORMAT 'YYYY-MM-DD')
The guy at support center wrote:
Talked to the customer. She sent me an E-mail that showed me that she had failed to include the DATE in front of the FORMAT on the INSERT statement. What is interesting is that she said this used to work in V2R2 and also sent me a Fastload where it did work. I tried a USING statement without a DATE in front of the FORMAT in BTEQ and it failed both in V2R2 and V2R3 and it worked if we added the DATE. In her Mload problem when she added the word DATE in front of the FORMAT statement it also worked in V2R3.
Therefore I advised her to change all of her scripts to include the type in front of the FORMAT as this is what our documentation says is necessary. When she does that not only will her problem go away but if we fix the anomaly in Fastload in the future it will be transparent to her.
We now have determined that the customer is correct in that V2R2 did not require the word DATE in front of a FORMAT statement for both Mload and Fastload and V2R3 does not require it only for Fastload. Development chooses to let this situation remain as it is currently coded. I have advised any customers who ask about this situation to always add the word DATE to their FORMAT statements on Mload and Fastload as we might change this design in the future and if so that will guarantee that they will not have to change their scripts.
Since this problem has been totally defined and the customer is proceeding normally I shall close this incident.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|