1

I'm trying to port my system to SQL Database (Azure instance) from SQL Server 2012. I'm using Visual Studio 2013 and I have my .sqlproj with all the definition of my database inside.

Given that a number of SQL statements are not available in SQL Database (like "ON [PRIMARY]", filegroups, etc.), I should change a huge number of *.index.sql , *.pkey.sql, *.table.sql files. Unfortunately I still need to cope with SQL Server 2012 installations (some customers are still on that infrastructure), so I would like to have instead a simple way to switch between the "SQLAzure" vs. "OLD-2012" syntax.

E.g. something like Compilation Symbols would be useful, or similar tricks.

Anyone has a brilliant idea on how to manage such an issue?

Thank you very much!

cghersi

Cristiano Ghersi
  • 1,944
  • 1
  • 20
  • 46
  • SQL Azure is a subset of SQL2012. So if you make your project work in Azure, it'll also work on 2012. – trailmax Aug 09 '14 at 22:46
  • @trailmax: unfortunately I need some features on on-premise installations that are not available on Azure, e.g. Free Text Search. So I would like to switch the contexts to have the capability to use the full feature set in on-premise installations and the reduced one in Azure. – Cristiano Ghersi Aug 10 '14 at 18:21
  • Ouch! You might end up with maintaining 2 sets of scripts: one for Azure, one for 2012. However, you might have more luck with answer on DBA Stack, just spell out what you have in your 2012, but can't in Azure and people there might be able to suggest something more useful than my blahberring here -) – trailmax Aug 10 '14 at 23:14
  • 1
    Thank you, I have posted the same question here: http://dba.stackexchange.com/questions/73709/how-to-cope-with-sql-server-2012-vs-sql-azure-database-sql-files – Cristiano Ghersi Aug 14 '14 at 15:59
  • 1
    I think it'll be useful there to link to this discussion - gives a bit more insight into your problem. – trailmax Aug 14 '14 at 16:18

1 Answers1

0

You could use a migration tool like Sql Azure Migration Wizard (not an official tool, but really good) and then generate the *.sql scripts that are used on SQL Database (SQL Azure). Then you can create a new project that only has those files when you target SQL Database (SQL Azure).

Panos
  • 1,953
  • 1
  • 14
  • 15
  • Thank you Panagiotis, unfortunately there's a big amount of files that would need to be replicated in the new project. My fear is that if I do a change in one file, than I need to remember (and all my team-mats, the same!!!) to modify also the related "brother" file in the other parallel project. I would like to have a mean not to duplicate files with the same object, keeping the two versions in the very same file. – Cristiano Ghersi Aug 10 '14 at 18:24
  • Got it. Yeah my solution doesn't fit that scenario unfortunately. In the other hand, I'm not sure you can achieve that without re-writing part of the SQL files or modifying them. It has, some way, to detect if it targets SQL Database or SQL Server and that requires either what I suggested above or changing what you already have. – Panos Aug 11 '14 at 19:44