Post reply

DT_DBTimeStamp woes with unchangible Source & Dest

  • August 26, 2008 at 5:26 am

    #127241

    Someone help me!

    I have a TimeStamp column in my SQL Server which I am not allowed to change the data type of. I have a flat file which (in 2000) uploads the table and uploads data into that timestamp column (somehow). So I set the flat file connector value to DT_DBTimestamp. But when migrating this task to SSIS, I get an error because SSIS doesn't want to convert the value in the flat file to an actual timestamp.

    I got the DT_DBTimeStamp and DT_Bytes error, so I tried changing the metadata in my flat file connector to DT_Bytes. Since the value in that column tends to be stuff like 20080825, SSIS didn't like that. Now I get 2 errors, "Failure to insert into read-only column "MyTimestamp"" and "Column metadata validation failed." and a validation warning about "Truncation may occur".

    So I tried changing the FFConnector metadata to DT_DBDate. That got rid of the extra errors, but then gave me the "Converting DT_DBTimestamp and DT_DBDate" error which was similar to the first error I got.

    My major problem is that I am not allowed to change the flat file or the database datatype. These are third party generated items. The only things I'm allowed to touch are the stupid DTS packages.

    Any thoughts as to a solution?

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • August 26, 2008 at 7:07 am

    #863094

    Do you understand that TIMESTAMP is not a date? It automatically changes every time an update is made to a record.

    This is a data type that is used for row versioning and you would typically not insert into it.

  • August 26, 2008 at 7:47 am

    #863125

    Michael,

    I understand that perfectly. But I don't know DTS very well, so trying to figure out what the package was actually doing was driving me batty.

    I just discovered my REAL problem, BTW.

    Destination table has 16 columns, flat file has 16 columns and one of those damn FF columns is UNUSED! Grrrrr. No wonder I'm confused.

    Apparently the program that generates my flat files generates far more columns in the text files than we actually need. Which I didn't figure out until I went to the mainframe programmer and asked her to generate a list of what columns (and the sizes) were used to generate the files.

    So now the problem is irrelevant since I realized that I am working off of faulty data (so to speak).

    Thanks anyway.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply