I am working on Visual Studio 2012 with Update 2 + SQL Server Data Tools and I am able work on the SQL Server Database Projects.
How do I create/add new SQL Agent JOB into this database project? Because if I click Add - New Item... I don't see anything for Job.
I know Jobs are related to SQL Server and the Database Project is related to a SQL Database. But I was wondering how do manage the SQL Jobs?
Thanks,
Prabhat
Jobs aren't supported natively. It might be possible to add these from the post-deployment script, although it's not something I've tried.
Creating server agent objects are not supported by visual studio database projects; however you can add your job by calling dbo.sp_add_job stored procedure.
The easiest way will be:
Create your job by SSMS and copy the script.
Control the job is already exist at database or not at your post deployment script. if it is exist delete at first; or you are going to have an error during deployment. you can do something like below:
DECLARE #JobID BINARY(16)
SELECT #JobID = job_id
FROM msdb.dbo.sysjob
WHERE (name = N'NameOfYourJob')
IF (#JobIDdel IS NOT NULL)
BEGIN
EXECUTE msdb.dbo.sp_delete_job #job_name = N'NameOfYourJob'
END
Paste your script for creating job to post deployment script.
For feeling more safe you can check the job is working at the moment or not and
you can disable job also before deleting.
Disable a job
Check job status
Related
I currently have an ASP.NET Core 2.0 project and I've just implemented code first migrations to the localdb and have around 3 migrations including the initial create. I'm wondering what the correct process is to change to a new database? Is it simply a case of updating the connection string and running the below in the project directory?
dotnet ef database update
My current knowledge is based on the below Microsoft tutorial and I've been using the CLI commands.
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/migrations
In answer to my own question, it does appear that running the following command in the existing project directory will build a new database from scratch including all the existing migrations. As long as you update the connection string to the new database and have already implemented migrations on the existing database.
dotnet ef database update
correct process is to change to a new database
Everything depends what you mean by writing this sentence ( I am not sure what "new database" means in it) altough flow looks like this:
1. First you make initial create
2. Then you change something in your code (create some additional fields etc)
3. Then you write "dotnet ef database update" command in CLI to update your current database.
I'm using Entity Framework with a code first model; I've got my InitialCreate migration setup and working locally, I can run code against my database context, and everything works.
But when I deploy my project to Azure, I just get a connection string error ("Format of the initialization string does not conform to specification starting at index 0.").
I can't seem to find where in the Publish dialog are the options to create the Azure database. -- Do I have to create the database separately and hook them up manually? -- If so, what exact process should I follow. Does the database need to have contents?
I thought Microsoft was making a big deal that this could all be done in a single deploy step, but that doesn't seem to be the case from my current experience.
When you publish your project in the publish dialog, there is an option for the code first migration in the Settings tab, it will automatically show your data context and it will give you the option to set the remote connection string, and this will add a section in web.config to specify the data context and the Migration class to run during the migration process.
It will also allow you to set if you want to run the code first Migration or not.
You can also take a backup from the dev and clear the data then upload it to Azure SQL DB, this way the code first data context will check at first connection and it will find the code an database the same
We have a SQL Server Database Project (.sqlproj) in Visual Studio 2012 that we use as source control for our database schema. One of the cool things that it does is generate the SQL to update the schema when we release code.
We have 3 profiles setup - dev, test, live - which is all working fine.
Recently we changed our live database from "Simple" Recovery to "Full" Recovery. Everything was great until we tried to run our next deploy to dev and test. We don't want to change the recovery mode from Simple to Full on dev and test - there is no need for us to change it. However when we publish the database project it now wants to set it.
I want to set the recovery model based on which publish config I am using. I have tried creating a variable and assigning that in the projects xml:
<Recovery>$(RecoveryModel)</Recovery>
but it still tries to set it to "Full" in the deploy script:
:setvar DefaultDataPath "C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\"
:setvar DefaultLogPath "C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\"
:setvar RecoveryModel "Simple"
GO
:on error exit
GO
/*
Detect SQLCMD mode and disable script execution if SQLCMD mode is not supported.
To re-enable the script after enabling SQLCMD mode, execute the following:
SET NOEXEC OFF;
*/
:setvar __IsSqlCmdEnabled "True"
GO
IF N'$(__IsSqlCmdEnabled)' NOT LIKE N'True'
BEGIN
PRINT N'SQLCMD mode must be enabled to successfully execute this script.';
SET NOEXEC ON;
END
GO
IF EXISTS (SELECT 1
FROM [master].[dbo].[sysdatabases]
WHERE [name] = N'$(DatabaseName)')
BEGIN
ALTER DATABASE [$(DatabaseName)]
SET RECOVERY FULL
WITH ROLLBACK IMMEDIATE;
END
My current work around is to create a script in the Post-Deployment folder to work out which server I'm on and then set the recovery model back to simple if it's dev or test. This doesn't seem like the best solution.
Is there a way to set database properties with SQLCMD Variables?
I know this is an old question but I thought I would suggest this solution. Why can't you just run a Post Deployment script to set the recovery mode.
USE [MYDATABASE];
IF ##SERVERNAME= 'DEVSQLSERVER'
BEGIN;
ALTER DATABASE [MYDATABASE] SET RECOVERY SIMPLE ;
END;
If one were using VSTS: As I see it there are three ways to go about handling this situation (i.e. Recovery mode setting in DACPAC overwriting Recovery Mode in your database(s)).
Alter your VSTS Build definition to replace your 'Database Option:Recovery' with the desired state in your *.sqlproj before the msbuild step (I'm not sure you can change this per Release environment or based on the branch you're building on, so kinda ugly and unworkable to start with unless you have a separate build definition per environment):
Replace <Recovery>SIMPLE</Recovery> with <Recovery>FULL</Recovery> or vice versa in the *.sqlproj file
Modify your VSTS Release to use the "SQL Server Database Deploy" task (i.e. don't use "Run a DACPAC file") AND specify in "Additional Arguments":
/p:ScriptDatabaseOptions=false
Modify your VSTS Release to use "SQL Server Database Deploy" AND specify a "Publish Profile". I think the "Deploy database properties" option in the profile is equivalent to "Script Database Options" but I've not tested it because 2 was a reasonable solution for me. One could pre-setup the different profiles before build time or attempt to change a master profile with variables for each Release environment. I really didn't want to complicate my life with this...
So in the end I chose option (2) above and tested with and without the /p:ScriptDatabaseOptions=false setting. It worked as expected. Choosing option (2) means that you'll need to setup your environment databases ahead of time. We use a Recovery mode of SIMPLE in our non-Prod environments and FULL in our Prod environment. To verify either open up the database options in MSSQL Mgt Studio or view the SQL Server Logs to see if a message like so appeared:
Setting database option RECOVERY to SIMPLE for datatbase 'WhatACoolNameForADatabase'.
If I needed to be able to stand up new databases as part of my release process then I may have to venture into the realm of option 3. If that is where you're at, then good luck and let us know what you had to do to make it work.
You can go to the project settings in visual studio. Click Database Settings > Operational and change the recovery model to SIMPLE.
I'm trying to import data from a SQL Server Compact (.sdf) database into a SQL Server database created through Visual Studio database project.
The .sdf database was created by a third party tool from an existant SQL Server database, and it is embedded into the Visual Studio project. The purpose is to deploy the database and insert initial values on a remote machine. I would like to run the import script as a post deployment script something like the following:
INSERT INTO Employer(
EmployerId,
EmployeeName
) SELECT
EmployerId,
EmployeeName
FROM sdfDB.dbo.Employer
Is it possible to reference a SQL Server Compact database (sdfDB)
in T-SQL script?
If not, what is the best practice to import data
into a freshly created DB from an embedded datasource which can be
deployed by build script in a remote machine?
1) Is it possible to reference a SQL Server Compact database (sdfDB) in
T-SQL script?
If you are thinking to something like this,
INSERT INTO [SQL SERVER Db].Table (Values)
SELECT (Values)
FROM [Sql Server Compact Db].Table
unfortunately no, this is not possible.
2) If not, what is the best practice to import data into a freshly
created DB from an embedded datasource which can be deployed by build
script in a remote machine.
You can use the SQL Server Compact Toolbox, that contains features to generate scripts from a Sql server compact file, that you can use to populate the SqlServer database.
Features:
Script!
Migrate a SQL Server Compact database directly to SQL Server (LocalDB/Express)
Migrate from SQL Server Compact to SQL Server, SQL Azure and SQLite via script (...)
(...)
EDIT
Also available in api form at exportsqlce.codeplex.com. Thanks ErikEJ for comment and great job!
The web applications I am installing can run against either a SQL Server or Oracle database. I need to be able to determine which database the user has (client is suggesting a property file) and then dynamically tell InstallShield whichSQL script to run, I know I can figure out how to determine which database is installed. My question is how do I configure the Feature/Component and tell InstallShield which script to use.
I don't have any Oracle servers available to me nor do I have the Oracle Instant Client. If I did, it seems I'd use a Basic MSI project included in InstallShield to build an Oracle Instant Client MSI and add it to my installer as a setup prerequisite. Kind of odd but I guess they couldn't get IBM / Oracle to play nicely.
So let's say I had all of that. I'd create a Sql connection that supported both MS and ORA SQL and build it. I'd run the installer with logging on and use the SQLLogin dialog to browse to a SQL instance and an Oracle Instance.
Then I'd look at that logfile and see if there's any evidence of the built-in InstallShield SQL custom actions setting a property that indicates the type and/or version of database server that it connected to. Hopefully something will surface because I didn't find anything in the documentation.
Once I figured that out, I'd use the property in a conditional expression so that the SQL scripts only ran on the type of database server they were intended.