I'm trying to get a windows Scheduled Task to open up MS Access DB (.mdb) which has an AutoExec macro that runs some queries and then exports it to a .csv replacing the .csv file that is already there.
From the command prompt I can run:
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE" "/Path to my Access DB"
and everything works perfectly. Access opens up, runs the query, and replaces the .csv with new data from the query.
When I try to do this with a Scheduled Task access just deletes the .csv file without ever replacing it and returns the error "the operator or administrator has refused the request".
Any ideas? I was looking for a quick way to get the data but I feel like I might be better off just writing some python to connect to Access.
I was able to return to this problem this week and finally found the solution.
The problem came down to the scheduled task. It was a local machine permissions issue and running the task with the correct domain that solved it.
First to fix the local machine permission I had to make sure that the user running the task had "Log on as a batch job" permissions.
Found at Control Panel -> Admin Tools -> Local Security Policy\Local Policies\User Rights Assignments -> "Log on as a batch job"
Second, because I was on a domain the schedule task had to be explicitly created by the domain user. I had to manually find the user on the domain during the creation of the task and remove the user that was auto populated by the task scheduled creation wizard.
Related
I have created an export task to export a view into an excel file onto a folder location. The task runs fine and exports to excel in the correct place. I ahve now saved this task in SSIS.
I am now trying to create a SQL agent scheduled job to run the task daily. I have SQLServerAgent and MSSQLServer access to the folder location however it keeps failing with the error:
Executed as user: NT Service\SQLSERVERAGENT. The process could not be created for step 1 of job 0x3FF5419F86864B47A653A928777E56DE (reason: Access is denied). The step failed.,00:00:00,0,0,,,,0
I have looked this up online and there were suggestions to try ticking the use 32bit runtime checkbox which i have also tried and still keep getting the same error.
Does anyone know what i can do to get the SQL agent job to run successfully?
I found the cause. The reason was I gave SQLServerAGent read/write access to the folder but it needed modify permission. Once i gave it modify it worked fine
I have created a SSIS Execute Task package to export CSV and write into d:/ drive
It works when i execute from SSIS.However when i run from SQLServer agent, the job shows sucess but the export file is not available in the location
Can anyone please advise if anything i am missing.
Thank you
I think that the issue is that the SQL agent doesn't have access to the file system location. Make sure that SQL service account has needed permissions:
Configure File System Permissions for Database Engine Access
I have psftp.exe installed on my server, and am using it to obtain files via sftp to be ingested into my sql server. I am using psftp.exe from the putty site to obtain it:
GET ZIP FILES:Error: In Executing "C:\Program Files\PuTTY\psftp.exe"
"XXXXXX#sftp1.XXXX.com -pw XXXXX -be -batch -b "D:\Code\XXXXX\XXXXXX.bat"" at
"D:\Data\ZIPFOLDER", The process exit code was "1" while the expected was "0".
The this works while in SSDT with no problems...however, when called by SQLSERVERAGENT on SQL SERVER, it fails.
to attempt to repair the issue, I have given NT SERVER\SQLSERVERAGENT full permissions on C:\Program Files\Putty\ and my Data drive D: where all of my code and data storage rests.
My problem is that while I think exit code 1 means a SFTP error (is it?) how do I troubleshoot?
Thanks.
UPDATE #1
as per instructions given by sandeep rawat, I added a windows user with administrative privileges and full control over the code and data sections of the server.
In addition, I created credentials associated with this use, and assigned a proxy user to those credentials.
Lastly, I reset the runas section in SQL SERVER AGENT's primary job to that proxy user.
Plus the setting in Internet Options.
I am still getting the same response.
THanks.
This type of issue generally happens when sql AGENT try to launch the DOS window which is the reason for the package to hang. and fails.
1 Change Window style property to hidden in process tab
2 Give the cmdExec permission to your SQL Agent account.
https://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/
3 Add the local drive to your trusted Intranet Sites by opening Internet Explorer and go to Internet Options > Security > Click Local Intranet > Sites and add your drive location as shown below
I am trying to create a simple SSIS package that can be deployed to a VM on another domain (same computer) that has SSIS on it. The package that I have created will transfer data if I simply run the data flow from SSDT on the source computer, but when I try to deploy and execute it, it appears to have 2 errors. The first being that it cannot open the datafile "C:\SSIS\Product Data.txt". The second being that the Flat Files Source 1 failed the pre-execute phase. I think that the second error is caused from the first. Does anyone know how to create a package that can transfer data to another computer without the flat file source?
Thanks in advance!
C:\SSIS.... will refer to the local C drive of the computer that is executing the package. So if you have it on the VM it would be at the \VM\C$. Typically it means 1 of 2 things.
1) The file path is not correct and you are not referencing where the file actually is.
2) the user you are executing the package as does not have permission to that file.
So where is the file is it on the C drive of the machine you are executing the SSIS package on? The answer to that wasn't clear in your question.
Second how is the file being executed? manual execution such as DTS_Exec? SQL Agent? T-SQL? If manual then the user logged in executing the task must have permission, if SQL Agent then the sql agent service account and possible the sql server service account have to have permission to the file, and T-sql sql server service account needs to have permission.
When it is local file path then a local user or domain user will work for the service accounts. If network path then the local user used for service account won't work and you will need to setup a way to run as a different credential.
Dear Stackoverflow users,
I have a SQL Agent Job which generates a specific report in PDF-file and then copies the PDF to a network directory and then deletes the PDF file in the source directory.
The SQL Jobs consists of 2 steps:
1. Generate the report
2. Copy the report to the network location.
For step 2 I made a bat-file which handles the copying and removal of the pdf file.
The bat-file is as follows:
set source_dir=C:\Reports\Energie\Uur
set dest_dir=\\KWS2-WEB-SERVER\Share\Reports\Uur
C:\Windows\System32\Robocopy.exe %source_dir% %dest_dir% /MOV /Z
However, when I run my the Job, it hangs on the second step. The status just stays on "Executing".
This is the line which I stated in the step (location of the bat-file to execute):
cmd.exe /c "C:\Reports\rapport_uur_copy.bat"
My job-settings are as follows:
Step 1
Type: Operating system (CmdExec)
On Success: Go to the next step
On Failure: Quit the job reporting failure
Step 2
Type: Operating system (CmdExec)
On Success: Quit the job reporting success
On Failure: Quit the job reporting failure
Some facts:
I have read/write permissions on the network directory
I run the steps as the Administrator-account (the logged in user, default)
Step 1 succeeds
I run Windows Server 2008 R2 Standard
I have SQL Server 2008 R2
When I run the script from the cmd manually, it works (under Administrator account).
Thanks in advance!
when a batch script needs to use drives not local, eg shares it always needs special rights, means you need to use an account to run the script which is allowed to log on as batch task in secpol - (click start type secpol.msc and start it - Select "Local Policies" in MSC snap in - Select "User Rights Assignment" - Right click on "Log on as batch job" and select Properties - Click "Add User or Group", and include the relevant user.)
too in normal batch it is not possible to use \\drives, they have to get mapped as drives with a char e.g. V:\drive and this mapping got to be made by the batch itself with the user account used running the batch i experienced this in a script of mine.