This has been driving me crazy. I have tried all suggestions and no go.
This absolutely does not work. The files are all still there.
The job runs successfully, but the files do not delete.
I recently ran into the same problem, and it was due to folder permissions. Easy enough to check:
Check the properties of a recent bak or trn file, security, and find out who the owner is.
Now check the properties of the backup FOLDER, security and see if the FILE owner from step 1 has enough effective permissions to delete files. The account might only have enough to create and modify, but not to remove files.
The peculiar part is that the plan always ran "successfully", even though it failed miserably. This is why teachers shouldn't let students grade their own tests. (grin).
What account is this running under? Domain Admin, service, etc?
I've always found it easier to create a batch job and use windows scheduler to clean up .bak files over x number of weeks. Can you look at the job history and see if the task failed / succeed, may be worth looking at the event viewer on the server as well.
The only solution I could find was to take the SQL that was generated from the cleanup task, and run that in an SP instead, 'cause guess what??? The SQL that this plan generates, runs perfectly!!!!!
This is the code I am using to run and it works.
ALTER PROCEDURE spUtility_delete_OldBackups
AS
DECLARE #date varchar(28)
SET #date = CONVERT(varchar(28),DATEADD(DAY, -5,GETDATE()))
EXECUTE master.dbo.xp_delete_file 0, 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\', 'bak', #date,1
EXECUTE master.dbo.xp_delete_file 0,'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\','diff', #date,1
EXECUTE master.dbo.xp_delete_file 0,'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\','trn', #date,1
I have a similar job that runs with no problems, what account does SQLServerAgent run under, these maintenance plans execute as SQLServerAgent, if the security context that SQLServerAgent runs under does not have adequate permissions, this job will fail, there should be some job history that will tell you more though.
Related
this is one that has me stumped and Ive been doing this a long while.
Migrating to SQL server 2016, large number of ETL. Easy enough.
One of the ETL packages has a simple script task to take a table of files, run a file exists foreach loop.
it uses a project parameter to create the unc ( \servername\share) and then binds that to the file name in the script task.
use an environment config setup in SSISDB
execute in SSDT works fine, deploy to catalog and it cant see the file. i know youll say permissions, but ive permissioned everyone group to share and drive in case its that. SSISDB execution means it should be running under my security context and im domain admin, local admin and creator owner of the share.
even strangeR, i have created simple package to grab the contents of one of the files and import into a dump table in case permissions or pathway were duff ( even though they work in SSDT might be the enviroNment config in SSISDB). THIS WORKS FINE, therefore it cant be the envrionment setup of SSISDB being referenced.
please note this is not running from an agent job yet so wont be due to agent server account issue. need to get it running from ssisdb first then ill create an agent job
So -- script task cant see unc share, built from two variables, that works in ssdt and its running under same credentials...
Go
For what its work the script task code is
Dts.Variables("BolFileExists").Value = File.Exists(Dts.Variables("StrLoadFileLocation").Value.ToString & Dts.Variables("StrCurrentFile").Value.ToString)
This is a slightly different answer as it shows a different approach and removes the script task. I use a foreach to check if the file exists using GUI tools provided by SSIS:
Well I found the answer and I deserve to punch myself in the face.
Tried everything, it was a file variable and path variable being pulled together in the script task so tried concatenation that before the script task, pumped this into a table to ensure it was going to write table.
Literally everything was fine and still didn’t work.
The issue....
Building it as a 2017 package onto a 2016 Sql server.
I’ve not found what was missing dll wise but it must have been one of those that meant the script task couldn’t find the files but weird it didn’t break and just said the files weren’t there!
Thanks all for input, I’m going to go put my head in the door and slam it
I have three SSIS packages to sync data from SharePoint to SQL Server, I have put them in task schedule to run daily, but one or two of them failure sometimes.
The error message from task schedule is
action "C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe" with return code 2147942401"
And my task is running using a service account:
"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe" /F E:\SSIS\Package.dtsx /Conf E:\SSIS\config.dtsConfig
If I uncheck the Run whether user logged on or not, then all goes fine.
It seems the package can't connect to the SQL Server that I config in config.dstConfig when failure. The failure also cause my db account been lock out.
But why only one or two package failure, not all?
And why everything goes fine if I run manually?
Any help is appreciated.
After much work, I found out the schedule task fail because the SSIS package validation failed before run. It's not a permission issue. But still no idea why only fail in task scheduler.
You can do this workaround, it think it will solve your issue:
Instead of putting the full file path in the program/script textbox, use the Start in (Optional) field to put the folder that the dtExec file is actually in - Like so:
Check 'Run with highest privileges' Checkbox.
References
https://blogfodder.co.uk/posts/win-2008-task-scheduler-with-return-code-1-0x1/
How do you schedule a job in SQL Server 2016? I've done this in 2005 but going through the tree in SSMS I don't see anything that resembles any type of scheduling that I am familiar with.
Searching finds me nothing for 2016. In older versions I see references to Jobs and Agent but I do not see any of those choices. Could I not have permission? Do they have new names? I also can't find the activity monitor which I found to be very useful (especially for terminating my processes during debugging sessions).
As it turns out I went through a similar situation and had to find a workaround.
It is actually quite simple. Just have a batch file created to run msserver from shell, then schedule to run that on OS.
Assuming you're running on Windows, use Task Scheduler to run a file that goes:
sqlcmd -S servename -d database_name -Q "Query or procedure here"
I don't know if the nature of the job and the permissions you have would make this not feasable, but nevertheless, maybe it will be of help.
I'm running the copy database wizard on a 2008 R2 instance of SQL Server.
The database I want to copy is a SQL 2000 database.
I'm copy that database to another SQL SErver 2008 R2.
The wizard uses SQL authentication for both servers, and both are sysadmins.
When I run it, I get the following error (FYI I have tried both copying the logins and leaving them out):
Event Name: OnError
Message: ERROR : errorCode=-1073548784 description=Executing the query "sys.sp_addrolemember #rolename = N'RandomRoleName..." failed with the following error: "The role 'RandomRoleName' does not exist in the current database.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
helpFile= helpContext=0 idofInterfaceWithError={C81DFC5A-3B22-4DA3-BD3B-10BF861A7F9C}
StackTrace: at Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer()
at Microsoft.SqlServer.Management.Smo.Transfer.TransferData()
at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()
Any help would be appreciated!
Jim
My suggestion is dont use the copy database wizard. Create a full backup of the database on the 2000 server and then restore it on the 2008 server.
If you google "Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer Copy Database Wizard" you will find that many many people have gotten this same error or other nearly identical smo errors... no-one appears to have gotten past it.
That's isn't to say its impossible... just, restoring a backup is so much easier then the wizard or troubleshooting the wizard. Good luck.
The copy wizard had missed some security and IIRC it's caused by subtle differences in security tables, principals etc between the 2 versions.
Frankly, the easiest way is to do one of these two:
backup/restore
detach, copy, attach
If you don't have access to the O/S and can't get it, another option is to create the missing role(s) in the background as the copy runs. You have to catch it between the creation of the files and when it tries to reference the roles, but there are a few seconds in which to create them if you keep clicking execute - I managed to create 9 roles.
Unfortunately, you'll end up with the roles in another database too (while yours cannot be used) so those need to be deleted.
Of course, this is only an option when you really can't use the other method.
Though the answer which is using the backup technique solves the problem generally, after facing the same issue several times, I was able to trace down the root of the problem using the Event Viewer of Windows to that the Database Copy wizard, using the SQL Agent, will eventually create a Job for the agent to run, after which the Agent will run using its own credentials (i.e. the credentials that you can look up in Windows Services, in my case, NT Service\SQLAgent$SQL2014)
All you need to do is to go the folder where SQL Server creates DB files (e.g. C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA by default for SQL 2014) and give the SQL Agent windows user write/read access on the folder.
The reason can be that a file with the new Database name already exist on the filesystem. We encountered this when we renamed Database X to X_Old, and tried to copy database Y to X. This cannot be done, because database X_Old is still associated with the filename X.
Either delete the conflicting database, or rename the file on the file system.
See http://codecopy.wordpress.com/2012/01/03/error-while-copying-a-database/
I have a vb script which moves files from one server to another and it works successfully when run manually but when a job is created in SQL Agent to automate the process it doesn't perform the task. SQL Agent doesn't fail it simply does not perform the move.
I granted local admin rights to the account performing the task and still nothing. I copied the files manually to the local SQL Server but I still get the same outcome when attempting to run the job in SQL Agent.
I also tried using FQDN but it still doesn't perform the process. Any suggestions? Please help and thanks in advance.
if you have 32 bit try:
C:\Windows\system32\config\systemprofile\Desktop
For the package to work. If you do not have Destop folder, create one and it should work.
Try to check: C:\Windows\SysWOW64\config\systemprofile\Desktop folder for the package to work.