Patrick_McD
asked on
Integration Services forcing conversion from datetime to timestamp
I'm working on an Integration Services package in SQL Server 2005 and I have created a destination table in a SQL Server 2005 database. DateColumn1 in this table has a datatype in SQL Server of datetime. The source uses a date with a DT_Date data type in Integration Services. When I execute the package I get the following error:
Validation error. TransformTask: SQL Server Destination [699]: The column "DateColumn1" can't be inserted because the conversion between types DT_DATE and DT_DBTIMESTAMP is not supported.
I can right click on the destination table and select Advanced Editor to try to change the External Columns datatype from "database timestamp [DT_DBTIMESTAMP]" to something like DT_DATE or DT_DATETIME, but it changes itself back to timestamp.
I get this same error with other packages every time I try to drop date data into SQL Server 2005 from Integration Services. Anyone know a solution? Thanks!
Validation error. TransformTask: SQL Server Destination [699]: The column "DateColumn1" can't be inserted because the conversion between types DT_DATE and DT_DBTIMESTAMP is not supported.
I can right click on the destination table and select Advanced Editor to try to change the External Columns datatype from "database timestamp [DT_DBTIMESTAMP]" to something like DT_DATE or DT_DATETIME, but it changes itself back to timestamp.
I get this same error with other packages every time I try to drop date data into SQL Server 2005 from Integration Services. Anyone know a solution? Thanks!
ASKER
Yes, they both contain fields with datetime columns:
--Source Table (in SQL Server 2005):
USE [SpiralIS]
GO
/****** Object: Table [SDRT-Spiral].[SDRTImport] Script Date: 03/24/2006 13:13:43 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [SDRT-Spiral].[SDRTImport] (
[DateImportColumn1] [datetime] NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
--Destination Table (in SQL Server 2005):
USE [SpiralIS]
GO
/****** Object: Table [SDRT-Spiral].[SDRTInitial Scrub] Script Date: 03/24/2006 13:10:00 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [SDRT-Spiral].[SDRTInitial Scrub](
[DateColumn1] [datetime] NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
--Source Table (in SQL Server 2005):
USE [SpiralIS]
GO
/****** Object: Table [SDRT-Spiral].[SDRTImport]
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [SDRT-Spiral].[SDRTImport]
[DateImportColumn1] [datetime] NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
--Destination Table (in SQL Server 2005):
USE [SpiralIS]
GO
/****** Object: Table [SDRT-Spiral].[SDRTInitial
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [SDRT-Spiral].[SDRTInitial
[DateColumn1] [datetime] NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Everytime I create a table in SQL Server 2005 with a column with a datetime data type, and look at it in SSIS under the Advanced Editor, it shows up as a datetime data type. I've created several new tables and they all do that.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry, I wrote my comment wrong. I meant to say that it shows up as a timestamp.
I decided to try another approach. I changed both the source and destination in SSIS to timestamp, while leaving the actual SQL table as a datetime. When I ran the package this time, I didn't get any errors and the data in the table was in fact a datetime. So, it's weird, but this workaround seems to function.
Thanks for your help!
I decided to try another approach. I changed both the source and destination in SSIS to timestamp, while leaving the actual SQL table as a datetime. When I ran the package this time, I didn't get any errors and the data in the table was in fact a datetime. So, it's weird, but this workaround seems to function.
Thanks for your help!
for both source and destn tables..