August 15, 2011 at 12:50 pm
rfr.ferrari (8/15/2011)
what's your data source??is a table? in another server, for example Oracle or Text File?
the destination table, we know!!
Yes my SOurce Table is Orcale... but it doesn't have Date column, Hence Added Derived COlumn in b/w Source and Destination
August 15, 2011 at 1:04 pm
What formula did you use for your derived column? What was the data type that you chose as your output? What inputs did you use for it?
August 15, 2011 at 3:35 pm
kramaswamy (8/15/2011)
What formula did you use for your derived column? What was the data type that you chose as your output? What inputs did you use for it?
(Dt_DBTimeStamp)Getdate() .... this is the one in the Derived Column
And then mapped this as an input to the Destination ( column Smalldatetime )
August 15, 2011 at 7:16 pm
(Dt_DBTimeStamp)Getdate() .... this is the one in the Derived Column
And then mapped this as an input to the Destination ( column Smalldatetime )
try this: (DT_DBDATE)GetDate()
August 15, 2011 at 7:45 pm
quillis131 (8/15/2011)
What makes me Nuts: It was all good in Dev environment, and then deployed it onto Producation ( here it turns out to be crashed) with an errror saying that overflowed...Its very suprising to me.....
Not really a surprise, different data between Dev and Prod, usually.
http://msdn.microsoft.com/en-us/library/aa258277(v=sql.80).aspx
Datetime: January 1, 1753 through December 31, 9999
SmallDatetime: January 1, 1900, through June 6, 2079
9999 is occassionally used for an 'end of time' date, or an unknown date.
I personally would ask your oracle guys to do a doublecheck on their data for outliers to the smalldatetime range in production.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
August 16, 2011 at 11:14 am
Evil Kraig F (8/15/2011)
quillis131 (8/15/2011)
What makes me Nuts: It was all good in Dev environment, and then deployed it onto Producation ( here it turns out to be crashed) with an errror saying that overflowed...Its very suprising to me.....Not really a surprise, different data between Dev and Prod, usually.
http://msdn.microsoft.com/en-us/library/aa258277(v=sql.80).aspx
Datetime: January 1, 1753 through December 31, 9999
SmallDatetime: January 1, 1900, through June 6, 2079
9999 is occassionally used for an 'end of time' date, or an unknown date.
I personally would ask your oracle guys to do a doublecheck on their data for outliers to the smalldatetime range in production.
I tried out 2 secenarios:
1st: (Devlopment BOX)
(i)I execute this package with Different DataBase(1) as Destination with Datatype from the Derived column Transformation as [DT_DBTIMESTAMP]. It's Good, there was no error.
(ii)Tested out with same DataBase(1) with [DT_DBDATE] as Datatype from Derived Transformation ( where only date is picked up yyy/mm/dd). Its's Good even.
2nd Secenario: (Producation BOX)
Note: I went on to Prod machine, and changed the Destination to DB(1).
(i)I execute this package DB(1) as Destination, and the Datatype as [DT_DBTIMESTAMP] from Derived Transformation. It's no Good, there was a error.
Error : "Conversion failed because the data value overflowed the specified type."
(ii) Tested out with same DB(1) with [DT_DBDATE] as Data type from the Derived Transformation ( where only date is picked up yyy/mm/dd). Its's Good.
I don't understand the logic behind this, When its writing to same table(Structure), Why its falling on the Producation Box????.... Itseams like, Smalldatetime Datetype on the DB(1) is no longer working ( as [DT_DBDATE] conversion got sucessful) .....
GOD ....can't get out of this, @&*Kin**^$ ERROR.....Someone Save me PLZZZZZZZZZZZZZ
August 16, 2011 at 11:32 am
Have you tried capturing the errors? On the step which is failing, go to your error configuration manager, and choose to redirect error. Then place an OLE DB Destination, direct the error output to the OLE DB Destination, and choose to create a new table to store the output.
Look at the rows which are producing error outputs. Paste them here, maybe we can find something out from that.
August 16, 2011 at 11:43 am
....
(ii) Tested out with same DB(1) with [DT_DBDATE] as Data type from the Derived Transformation ( where only date is picked up yyy/mm/dd). Its's Good.
the 2nd situation, worked on your production server??
August 16, 2011 at 12:10 pm
quillis131 (8/16/2011)
Evil Kraig F (8/15/2011)
quillis131 (8/15/2011)
What makes me Nuts: It was all good in Dev environment, and then deployed it onto Producation ( here it turns out to be crashed) with an errror saying that overflowed...Its very suprising to me.....Not really a surprise, different data between Dev and Prod, usually.
http://msdn.microsoft.com/en-us/library/aa258277(v=sql.80).aspx
Datetime: January 1, 1753 through December 31, 9999
SmallDatetime: January 1, 1900, through June 6, 2079
9999 is occassionally used for an 'end of time' date, or an unknown date.
I personally would ask your oracle guys to do a doublecheck on their data for outliers to the smalldatetime range in production.
I tried out 2 secenarios:
1st: (Devlopment BOX)
(i)I execute this package with Different DataBase(1) as Destination with Datatype from the Derived column Transformation as [DT_DBTIMESTAMP]. It's Good, there was no error.
(ii)Tested out with same DataBase(1) with [DT_DBDATE] as Datatype from Derived Transformation ( where only date is picked up yyy/mm/dd). Its's Good even.
2nd Secenario: (Producation BOX)
Note: I went on to Prod machine, and changed the Destination to DB(1).
(i)I execute this package DB(1) as Destination, and the Datatype as [DT_DBTIMESTAMP] from Derived Transformation. It's no Good, there was a error.
Error : "Conversion failed because the data value overflowed the specified type."
(ii) Tested out with same DB(1) with [DT_DBDATE] as Data type from the Derived Transformation ( where only date is picked up yyy/mm/dd). Its's Good.
I don't understand the logic behind this, When its writing to same table(Structure), Why its falling on the Producation Box????.... Itseams like, Smalldatetime Datetype on the DB(1) is no longer working ( as [DT_DBDATE] conversion got sucessful) .....
GOD ....can't get out of this, @&*Kin**^$ ERROR.....Someone Save me PLZZZZZZZZZZZZZ
Sorry if I wasn't clear. The problem here is not the destination, but the SOURCE data. The source data has something outside the range. Try running in production from the DEV source, and see if you recur the same issue. If you do, it's environmental, if you don't, it's data source.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply