Metadata, rather than actual data? What sort of metadata?

Are you truncating the target tables first? If not, how are you avoiding duplicates?

Might be simpler to perform a backup/ restore - have you considered that?

Are the packages being executed with a logging level of 'NONE', perhaps?

Another option to try is to setup local configs with the pw and see if that works. From the Parms screen click the "Add Parameters to Configuration" button and...

Try

DROP TABLE IF EXISTS ##tmp

instead.

• This reply was modified 4 years, 3 months ago by Phil Parkin.
• This reply was modified 4 years, 3 months ago by Phil Parkin.

Script the creation of one of the troublesome logins and check the DEFAULT_DATABASE for it.

Add

using System.IO;

to your 'using' block and it should fix that.

That's not enough information to enable us to help.

Are there any clues in the All Executions report (All Messages)?

What is different about this package? Software versions? Different instance?

There was a time when I had some reliability issues with the FST...

I can create a File System Task to move it to an Archive Folder using some C# script:

This is known to the rest of the SSIS world as a Script...

What about if that file is not removed from the folder at the end of the day and another is not put in its place... will it not reprocess...

Rather than going through all that, an alternative might be to run the package every 15 minutes (or whatever) between 8am and 10am.

If no file is found, the package completes...

I imagine you have a reason for setting the variables as string in the package, but if not, why not just make them INTs?

Alternatively, create two new INT variables and...

That is just one issue, and the error message seems clear. This is running on the server and therefore (presumably) it cannot access that path when it runs.