Tag: SQL Change Automation

In my last post, I started out with a new SCA project, getting a connection to my database up and running. Now, let’s start the new project by adding some objects.

Adding Objects

I’m going to start with a couple objects to make this simple, but we’ll move on from there in other posts to describe the options and details.

Our database is not terribly useful without tables, so let’s create a table. I’ll start by using a query window to build a table. Right click the database and choose New Query.

Once this opens, let’s write a query. I’m comfortable building tables like this, so I’ll add the first table to hold my SQL Server builds.  I’ll write the code shown below and then execute this.

At this point, the development database has a change, but it’s not in my project. I need to use the SCA pane to let VS know that I’m ready to import this change. Open the pane and click refresh. The following should appear when the process completes.

In this dialog, we see a new table was found. The process compares the Shadow database, where no changes have occurred, with the development database, which has a new table. This gives me a “diff” in essence and I can add this to my project.

The change is checked on the left, so I can click the Import and Generate Script button. I’ll do that and I see the image below. There’s a lot here, so let’s discuss this after the image.

The first thing to look at is the script that’s active in the upper pane. If you notice, the tab name is on the right side of that upper left pane, highlighted in blue. This is my first migration script. You can see the migration ID at the top and then a PRINT statement, which is useful for logging during the build or deployment process, then the top of my code.

On the right side, in the Solution Explorer, we see that my script has been added to the Migrations folder. The default name has been applied, but I can rename this if I want.

In the SCA pane, we see a few things. First, the change is grayed out because the change was scripted.  Above that, we have a yellow bar that notes a migration was generated, and it gives us the path in the project. Finally, there is a “Refresh” button to verify the script. We want to click that. This will use our script with the Shadow database to verity the code is correct. Once I click that, I get a note that the project was verified.

At this point, the Shadow and development databases are in sync.

This tells me that my changes should work when I deploy them to another system. Hopefully that works, and we’ll tackle that next time.

One of the ways that you can more easily perform database development tasks is with SQL Change Automation (SCA). This is a plug-in from Redgate that works with Visual Studio, and while there are tutorials on Setting up SCA and starting in VS, I wanted to add my own take that might make this a little easier for some people.

This is a short Proof of Concept (PoC) that gets you started, and I’ll add in more features over time in future articles. I’ll use the idea of a database of builds for SQL Server, which is a project that you might find useful in your organization.

Starting in Visual Studio

If you’re an application developer, you are familiar with building new projects. If you’re not, you can probably figure this out, but I’ll just describe and explain the process. In the File Menu, we start our PoC with a File New.

Once you do this, you’ll see a large list of project templates or types. You can see the recent, installed, or even online types. These are broken into a weird mix of languages and target platforms, but in any case, SQL Server is relegated to the “Other”. Along with SSDT projects, if SCA (or ReadyRoll) is installed, you can choose this type.

Once we do this, the project is created, and an outline appears in the Solution Explorer. Before you can go there, SCA pops up a Getting Started dialog. This is designed to help you get moving since the project doesn’t necessarily lend itself to an intuitive flow.

Let’s get started, as it says. The next screen you see is the database connection. This is a slightly confusing dialog to some, but it makes sense once you understand the purpose. We have two connections with buttons and some links, as shown here.

The left side is the development database. The instance chosen is also going to be the place where your shadow database is created. You can pick an existing database here by picking the instance and database in the connection dialog. Alternatively you can create a new database, where you’ll specify the details.

The right side is the target database, which is the downstream target you’ll use for deploying code. This could be production, or it could be a QA database. Either way, this is a default target, and this can be overridden with parameters in the SCA PowerShell cmdlets.

For now, let’s ignore the left and leave it blank. For the right, let’s create a new database. Once we click the link, we get this.

The default database is the name of the project. The default instance is a LocalDB instance, which is an in process SQL Server. This is named (loadldb)\Projectsv13 in the  current (Aug 2018) versions of SCA. I’ll leave this alone, but the Edit Connection link would allow you to pick a new instance and database.

Once this is created, we return to the dialog, seeing the dev database and the target, which we left blank. When we move forward, we see this dialog.

This is a reminder that we didn’t create a target, but that’s OK. We can do that later, especially since this is a new project. There is no baseline, which would be an initial script to rebuild the database to its current state. Right now our baseline is nothing.

I’ll create the project and go back to VS. Once I go that, I can see the database on the LocaDB instance in the Object Explorer. I also see the Shadow database here.

If I click Refresh in the SCA pane, I’ll get no results since there are no objects in the database.

Once this runs, I see that all objects are identical. This means the dev database and the shadow database have verified each other.

My project is similarly blank. In solution explorer, I see the outline of the project.

At this point, I can begin development. Migrations scripts I create will appear under the Migrations folder and if necessary, I can edit the pre and post scripts. Or add more scripts here. The default scripts are in place already, but I can change them as needed.

In the next post, we’ll start development.

I got this question recently from someone that was evaluating the SQL Change Automation client in Visual Studio. After setting up a new PoC (Proof of Concept), they were confused about why there is a new entry in their list of SQL Servers.

If you’re wondering, this is what you see in Visual Studio 2017, for the SQL Server Object Explorer.

In my case, I’ve actually got a few different instances since I’ve been working with the SQL Change Automation (SCA) for years, across a few versions.

As the instance names list, these are LocalDB instances. LocalDB is a version of SQL Server that is spun up in process, rather than a service. Other than that, it’s a real SQL Server instance that is running. In fact, if you want, you can connect to this with SSMS.

If I connect with those credentials, this will appear in the SSMS Object Explorer as well, the same as any other instance.

Why is this in SCA?

As an early part of the SCA product, when it was in ReadyRoll, there was a desire to not impose burdens on application developers. If you were working with a project for C# or ASP.NET and wanted to include the database, the idea was to keep things simple.

The simple way to get up and running is to use LocalDB, so no install, no worries with Express and a service running, just use LocalDB. This used to be more of a default, but now it’s just one of the options.

In my case, once I’ve setup my project to connect, the Shadow database, by default, is also right here, and I’ll see both databases under the (localdb)\Projectsv13 instance.

All of this is configurable, so you can set things to work in whatever manner works best for you. If you typically have a development instance, either local or remote, you can easily use those instead, and you’ll never need to worry about LocalDB. In fact, if this bothers you, you can disconnect or even delete the instance.

 

LocalDB is a lightweight way to work with SQL Server, but you don’t need to use it.