Offical team blog for SSDT, a tool for on and off-premise database development
SQL Server 2014 introduced a number of new enterprise features. The most notable of these are memory optimized tables and natively compiled stored procedures. When developing databases with enterprise features in Visual Studio there are a few best practices to be aware of.
We encourage users to apply multiple levels of validation during database development: live syntax error highlighting, build time validation, F5 debug deployment, and unit testing for comprehensive validation of actual behavior. Modify, build, deploy, and test.
F5 debug deployment is an important step in this validation loop but the default LocalDB debug target may not support all the features you use in your database. To validate databases with these features we encourage you to use an alternative SQL Server with full support. Common approaches include obtaining a license for a Developer Edition and installing a server on each developer’s machine, or using one server for the development team and applying a standard naming scheme to distinguish each developer’s tests databases from each other.
Regardless of which approach you choose you will need to change the debug target for your database projects. At present this is a manual step for each project in your solution.
For each project:
If you are updating multiple projects might be easier to update the user file. For a project Project1, this will be a file called Project1.sqlproj.user located in the root folder of your project. Edit this in notepad and add the following entries to specify the server name and an auto-generated database name to deploy to. Note that MyServerName should be replaced with the server you wish to connect to.
<TargetConnectionString>Data Source=MyServerName;Initial Catalog=$(USERNAME)_$(Name);Integrated Security=True;Pooling=False</TargetConnectionString>
Features not supported by LocalDB include, but are not limited to:
We strongly believe in the benefit of build time validation. At build time most issues that would block database deployment will be marked as errors and block project build. It is important to know that some new SQL Server 2014 features do not have this level of validation. Memory optimized tables and natively compiled stored procedures introduce a number of restrictions on TSQL syntax that will not be enforced at build time. The best practice to when implementing these features is to use the F5 debug deployment to catch any deploy time issues.
If you want to catch these issues earlier you could also add custom Static Code Analysis rules to catch these at build time. There are a number of examples of rules that check for SQL Server 2014-specific issues in our samples project. These are planned for inclusion in future releases of the database tooling as either validation rules that run automatically during build or as standard Static Code Analysis rules. Suggestions for additional rules are welcome and can be sent via our forum or Microsoft Connect page.
· Supported SQL Server Features
· Supported Data Types
· In-Memory OTP (In-Memory Optimization) main help page
I would like to know if the follow bug has been resolved...
I am urgently in need of this fix.
Please, reply me by email (firstname.lastname@example.org)