2

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

0

Rather than maintaining two separate code bases, the easier way to do this is by aiming for the lowest common denominator. Try to only use features in the database that are supported in Azure SQL DB. That way you'll have a single code base that works for both, and you'll have much easier upgrades, too.

For box-product customers that truly need SQL Server features that aren't available in Azure SQL DB, build a separate set of scripts that are deployed after the database is created.

If there are specific features you need in SQL 2012 that aren't available in Azure SQL DB, try posting separate questions about each of those (or list 'em in the question itself) so we can get a better feel for why you really need two separate code bases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.