Hi im developping an ssis package that imports excel files (.xlsx) from an ftp server to a local folder then they are imported to a sql server table . I'm using a foreach mapping to the name of files. untill here all think work fine .
i added a system file task that move (or remvove) the files from the local directory .
this task failed , i have this error :
*Attempted to read or write protected memory. This is often an indication that other memory is corrup*t
The hotfix to the .net runtime the fix appears to be https://support.microsoft.com/en-us/kb/923028 shall fix the issue
Related
I have an SSIS Package that as part of the process uses a File System Task to move a file to an archive folder.
The Source is a variable from a For Each Loop. The Destination is a File Connection with the connection string set to a Variable. The variable is static assigned in dev, and pulled from a package config when deployed.
Everything works in VS in the dev environment. I deploy to SQL Server and schedule with a SQL Job. Job fails. Immediately, I think it's a permissions issue but my Proxy has Modify to the destination and read on the source.
I then rewrite the package so the move file is done in a script task using system.io. Deploy that and it works with the same proxy account on the job, so it's not a permissions issue.
I'm happy it works, but want to know why it failed before.
The error I got when it failed was, "File or Directory "\destinationpath" represented by connection "archiveconnectioname" does not exist."
Has anyone any ideas?
I cloned an existing repository (repository created by a team in my office which deals with subscriptions in a certain app we are working on) which have some database migration files inside the path ..\internal\db\migrations , this is migration files path.
First of all i run the command docker compose up .for an existing docker.yaml , then i run the command go build then go run . .
I made a debug and the app reaches the point when it is about to run the migration file then it displays an error:
Failed to initialize App. Error: first D:\subscription-store: file does not exist
although I checked the paths through debugging and they are correct and at the same time the migration files all are exists.
I am using visual studio code as an editor, Go version 1.15 ,docker and MySQL. I am running on enviroment windows 10.
After debugging and searching , it was found that the repository uses some paths to get the migration files from the local drive . the paths was written for Mac in the code base and i cloned the repository on a windows machine so it didn't work .
The error specifically happened in the call of the function
migrate.NewWithDatabaseInstance(
fmt.Sprintf("file://%s", fullPath),
"mysql",
driver,
)
The generated path for the first parameter was
file//d:\\subscription-store\\....\\db\\migrations
And this is wrong for windows as the driver d: shouldn't be supported in the path .
it is resolved as following
"file:///"+"subscription-store\\....\\db\\migrations"
When the above URL sent to the function rather than the old one , it worked successfully.
I have a package I created that runs fine in Visual studio.
The package uses a for each file loop and the variable points to a folder like this:
C:\Users\Desktop\Folder\
However, once I deploy the package on SSMS, when I execute the package I get the following error:
Foreach File in Folder:Warning: The For Each File enumerator is empty.
The For Each File enumerator did not find any files that matched the
file pattern, or the specified directory was empty
Why do I get this warning in SSMS, but in VS it runs fine?
Note: The SQL Server is not hosted on my local machine.
If you use a local path to the folder, like this
C:\Users\Desktop\Folder\
Then when you run the package on the SQL Server, the files need to be in that LOCAL PATH on the SQL Server.
When you run it in Visual Studio, it looks for the files in the local path on your machine.
I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.
I have a .dtsx file (an SSIS package) that downloads files from an FTP server and imports data. It runs fine whenever I run it manually. However, when I schedule calling the package as a step in a SQL server agent job, it fails. The step it fails at is the one where I call a .bat file. The error in the job history viewer says this:
Error: 2009-05-26 12:52:25.64
Code: 0xC0029151 Source: Execute
batch file Execute Process Task
Description: In Executing
"D:\xxx\import.bat" "" at "", The
process exit code was "1" while the
expected was "0". End Error DTExec:
The package execution returned
DTSER_FAILURE (1).
I think it's a permissions issue, but I'm not sure how to resolve this. The job owner is an admin user, so I've verified they have permissions to the directory where the .bat file is located. I've tried going into Services and changing the "Log On As" option for SQL Server Agent, and neither option works (Local System Account and This Account). Does anyone have ideas as to what other permissions need to be adjusted in order to get this to work?
I tried executing just the batch file as a SQL Job step, and it gave more specifics. It showed that it failed when I was trying to call an executable, which was in the same directory as my .bat file, but not in the windows/system32 directory, which is where it was executing from.
I moved the executable to the system32 directory, but then I had no clue where my files were being downloaded to. Then I found that there's a property for the Execute Process Task (the one that executes the .bat) called WorkingDirectory. I set this to be the directory where the bat is located, moved the executable back into the same one as the .bat file, and it's now working as expected.
For me it was a permissions issue. Go to Environment --> Directories, then change Local directory to something the SQLAgentUser can access. I used C:\temp. Click the dropdown for Save, and choose "Set defaults".
Are you executing the SSIS job in the batch file, or is the batch file a step in the SSIS control flow?
I'm assuming the latter for this answer. What task are you using to execute the batch file (e.g. simple execute program task or a script task). If the latter, it looks like your batch file is actually failing on some step, not the SSIS script. I'd check the permissions of what your batch file is trying to access
In fact, it might be a better idea to rewrite the batch file as a script task in SSIS, because you'll get much better error reporting (it'll tell you which step in the script fails).
You could try executing the batch file using the runas command in a command window. If you try and execute it under the local system or network system account, it should give you a better error. If it does error, you can check the error level by going "echo %ERRORLEVEL%".
If it wasn't the latter, and you're executing the SSIS package via a batch file, why?
Are you possibly accessing a mapped drive in your .bat file? If so, you can't rely on the mapped drive from within the service, so you'd have to use UNC path.
I had the same error and I resolved it by logging on to the user account that runs the job, opened Coreftp site in question there, test the site access, made the change there (in my case, I had to reenter the new password) and now it works.
So yes, it is an issue of file access. This one is file access to the coreftp site in question.