SSIS runs in debug but not from job

  • We have this SSIS where one of its components, reading a flat file and writing to a database table, runs fine when I execute the package in VS (debug) but when I run it using a job this specific step fails on the error:

    Error: 2012-09-09 15:31:58.43

    Code: 0xC0204026

    Source: Copy date from Folder file into FolderTable Save the file in the database [14]

    Description: The metadata for "[dbo].[FolderTable]" cannot be retrieved. Make sure the object name is correct and the object exists.

    End Error

    Error: 2012-09-09 15:31:58.43

    Code: 0xC004706B

    Source: Copy date from Folder file into FolderTable SSIS.Pipeline

    Description: "component "Save the file in the database" (14)" failed validation and returned validation status "VS_ISBROKEN".

    End Error

    I've looked around and tried various suggestions fixing the problem,like redefining the column and its length, changing the ValidExternalMetadata.

    Didn't help.

    What could help me with the problem ?

    How come it runs fine within VS but from a job it fails ?

    Thanks

    David

  • I'd guess a permissions issue. What account is the SQL Agent job running under? Does that user have permissions to see the folder where the flat file is?

    HTH,

    Rob

  • We've had the same issue due to permissions and we've had the same issue due to missing or out of date dll files on our server.

    Was this package developed by you? Are there any special "accessory" files (like dlls, webservice calls, etc) that are required to go along with it that perhaps don't live on the server?

    What account is running the job? Does it have access to both the database and the file share location?

    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.

  • Have you check the permissions of the account that runs the SQL Server Agent as already suggested? In order to be sure it is a permission issue you can also try to set your account to run the SQL Server Agent on a development Server and run the package from there.

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

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