I have this issue with the System Scheduler. I have created a project using Visual Studio 2010, then I have scheduled its execution at a certain moment of the day, but when I tried to see the execution result nothing had happened, the execution was never initialized. Just for check I created a very simple package that gets the information from one table to another, but when the execution is running using the scheduler the command window appears so quickly that I could not see nothing and besides the package was not executed.
I wonder if maybe there is a problem with this version of Visual Studio and the scheduler because with 2008 version I have never had any problem, and if there is a possible solution for this problem.
This is what I used to do:
First I create a .bat file with the next code
#echo off
dtexec /FILE "Path_to_my_package\Package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
echo Finishing........
exit
Then I specify in the System Scheduler that I want to run this package in a certain without any problem, and now this is not working.
As mmarie said, you should use SQL Agent for automating SSIS packages. The Visual Studio is irrelevant with this issue. If you used the normal scheduler, you should invoke DTExec and pass your package as an argument, you can check the link below for more details:
http://technet.microsoft.com/en-us/library/ms162810(v=sql.105).aspx
However, the better alternative is SQL Agent, where you can create a job and check the outcome in a better way. It is explained in details in the below link:
How do I create a step in my SQL Server Agent Job which will run my SSIS package?
Related
I executed an SSIS package using SSDT and Visual Studio. When I try to execute another package I get an error saying "The process cannot access the file XXXX.ispac because it is being used by another process". I have tried rebooting but that is a pain in the behind. How can I work around this error?
While developing an SSIS package I got the error “The process cannot access the file ‘.ispac’ because it is being used by another process”*.
Tried to close SSDT and run it again but, we still got the same error while compiling. Then, after searching over internet, we got the solution:
Solution :
Go to Task Manager–> Details Tab.
Locate the process “DtsDebugHost.exe“.
Kill this process.
There might be multiple instances of this process. Kill all of them.
After doing this, I tried to compile the package again and it was successful.
You might check your patch level. I saw this much more frequently with the 2015 release of SSDT but hasn't bit me too often since then.
Finding and killing a process
Sysinternals has an excellent tool called Process Explorer. It's free, doesn't require an install and helps you see what all is happening on your computer. In this case, you want to find the process that has its grubby finger on your file (MyProject.ispac) and then kill it.
https://helpcenter.gsx.com/hc/en-us/articles/115015880627-How-to-Identify-which-Windows-Process-is-Locking-a-File-or-Folder
A different approach that doesn't require getting Process Explorer running is to change your build from Development to Release (and back again).
Chicken Sandwich No Pickles asks via comments
How can I convert from Development to Release?
In your tool bar, click where you see Development in the dropdown (or right click the solution in Solution Explorer)
In Configuration manager, you may/may not have a listing available under Configuration. Earlier versions of SSIS projects had dev/release configurations predefined but it looks like newer ones do not. If you do not have another option, make one via <New...>
Copy the values from the Development configuration et voilà!
Now when you debug, ProjectFolder/bin/Release will exist and the dtsdebughost.exe will latch onto that file and release the pointers to ProjectFolder/bin/Development/Project.ispac
Here's a simple script you can run in powershell to kill all ssis debug process "DtsDebugHost.exe" and unlock the ispac file.
unlock_ispac.ps1
# if ssis error with 'The process cannot access the file ‘.ispac'
# run this file in powershell
get-process | foreach {
$pName = $_
if($pName.Name -eq "DtsDebugHost") {
$pName.Kill()
}
}
I have a visual studio load test which I want to run every hour so that I can start to collect some data.
To do this, I thought it would be best to make a little powershell script and put a command like this inside:
Invoke-Expression -command "& '$env:VS100COMNTOOLS..\IDE\mstest.exe'
/testcontainer:"C:\Users\benb\Documents\Visual Studio
2010\Projects\BBPerformanceTest\bin\Debug\HomePageOnly.loadtest""
That command works fine, but sometimes when its run I get a blue screen of death. However, when I run my load test through the visual studio GUI, I never get a BSOD.
two questions:
is it possible to avoid this BSOD?
Is there another way I can schedule my load test?
Thanks
I just called MStest.exe directly in the scheduled task (rather than indirectly through a powershell script). This seemed to solve the problem. Thanks
My first suggestion is to analyze the memory dump file to find the root cause of your crash (it might not be the load test). This article contains information on how to do that: http://support.microsoft.com/kb/315263
In response to your second question: you can also use a batch file instead of a powershell script.
I hope this helps.
Currently I'm using Visual Studio 2012 RC and SQL Server 2012 RTM.
I'd like to know how to re-deploy/re-create a test database for each test run.
Keep in mind I've a SQL Server database project for the database using Visual Studio 2012's template.
Actually I'm not very sure about an idea I got in my mind, but .testsettings file has Setup and cleanup scripts. Is this the way to go? For example, a PowerShell script reading the database project generated script and executing it against the database?
I guess there're better ways of doing that and it should be an out-of-the-box solution but I ignore it and Google doesn't help me in finding the right solution.
As mentioned you'll probably want to use the VS 2012 .Local.testsettings > Setup and Cleanup scripts to create / tear down you SQL Server database.
For the script you may want to use powershell with a .dacpac (rather than just a T-SQL script), since you are using a SSDT project. Here's a link to some example code - in particular you may want to take a look at the 'Deploy-Dac' command.
If you are unfamiliar with .dacpacs as the (build) output of SSDT-created database projects, take a look at this reference link.
Edit: Although this doesn't answer the question in a plain SQL Server way, an easy Entity Framework approach would be the following: I found that I could create and destroy my database every time correctly by using the DbContext.Database.CreateIfNotExists() and DbContext.Database.Delete() methods in my setup and cleanup phases of my tests.
The fastest solution, while a bit of a hack, is really straightforward. You can set the DB Projects properties under the debugging tab to "always re-created DB". Then test in two clicks, do a debug/build, then run all tests. You should get a freshly built DB on localDB for you tests to be ran against. You can also change the target for the debugging DB (again the DB projects properties) to whatever you want, so you can deploy to a .dacpac, or to an existing SQL DB or wherever. It means testing in two steps, and if your build is long, it may be annoying, but it works. Otherwise, I believe scripting is your only option.
Before applying a migration in EF Code First, you can ask to see the SQL script it intends to apply with:
PM> update-database -script
Unfortunately this opens a script named something like tmp939D.sql in Visual Studio and then freezes the IDE until it finishes generating the script. If the script is long, this is a long freeze. Is there some way to push this to a file on the hard drive instead of in the IDE? A way to specify the name of the SQL script file it generates?
See this answer for a solution: https://stackoverflow.com/a/14339379/219187
This solution does NOT use -Script, but takes a C# approach. We implemented it in a unit test, so our build server generates the SQL scripts after every software change.
I have a MSI package which on first install will install an SQL script onto an SQL Server. This works fine using the SQL Script feature within Installshield.
During a repair of the MSI, the SQL script is re-run. I want to prevent this from occurring, I only want the script to run on install only.
I have tried a number of things to do this:
Conditions on the Feature - Failed
Conditions on the component - Failed
Modifying the local feature selected registry entry at the end of the install - Failed
how can I prevent a feature / component (which is linked to the SQL Script) from been ran on a repair?
Thanks
While a SQL Script in InstallShield is associated to a component ( and therefore a feature ) the condition is on the script itself. Take a look at the Runtime tab page of the script and you'll see "Script Condition" at the bottom. This is stored in the ISSQLScriptFile table in the Condition column.
BTW, you might want to consider instead of trying to force the script to not run during a repair to get it to execute gracefully during the repair. In other words, if the purpose of the script is to create a table, have it do nothing if the table already exists. This way if the table didn't exist the repair would work and the table would get recreated. Specifics depend on the nature of the script in question.