Creating a Database Project without Local SQL installed

Question

I might be completely off on this, but is there a way to have a database project point to a remote server? My reason for asking is that we have a shared DEV Database for development use, and it seems like overkill for each developer to have a local instance of SQL Server as well. Is there a connection string that I can set or modify to point the remote server, or is the only way you can have a database project is to have a local instance on your machine. Please let me know if what I am asking does not make sense.

Thanks!

Answer 1

SQL Server Data Tools (which is what you're using for your database project) can work in two ways:

1. Connected Database mode.
2. Project oriented, offline database mode.

If you look at those articles. you will see that for development purposes, in both cases a localdb instance is needed. The local server is a limited SQL Server Express installation, which comes by default with Data Tools. So all you need to do is install Data Tools. If you already did, then you have localdb support. More on this from MSDN:

Microsoft SQL Server 2012 provides a local on-demand server instance, called SQL Server Express Local Database Runtime, which is activated when you debug a SQL Server Database project. This local server instance can be used as a sandbox for building, testing and debugging your project. It is independent of any of your installed SQL Server instances, and is not accessible outside SQL Server Data Tools (SSDT).

The workflow, for a central development database, would be:

• Create the database project and distribute it to each developer.
• Developers work "offline" and add/remove objects from the database.
• Before submitting the changes to source control, each developer also syncs the local database changes with the central development database.
• The rest of the team gets the changes from source control, so no manual sync needed. Only a new localdb publish would be required.

Of course, there are many other things to consider: local data (see here about replicating data to the real database), and some features not supported by localdb (like full text search).

I've tried this flow and works really well if you learn to control it. You always get a consistent central development database, without intermediary and unstable modifications.

Answer 2

You can change the "Debug" properties to point to a different server than the (localdb) instance. Most times you won't do this unless you're using some features that aren't supported in the (localdb). That would let you push the changes to your central server on each debug build. However, this could have a lot of unintended consequences if you're just playing around. The better option would be to leave the (localdb) debug instance alone and set up Publish Profiles for a real "Local" SQL Server install and for your shared Dev server. That way you can do all of your dev work offline and only push changes to the shared dev server when you're ready to do so.

I have a series of blog articles on SSDT at my blog that may be helpful: http://schottsql.blogspot.com. I'd also recommend looking at Jamie Thomson's blog at http://sqlblog.com - he has a lot of tips on DB and SQL Projects that could be helpful.