Our project is using EF code first approach, and it has quite a few stored proc.
Currently we generate DbMigration code like this
var scripts = StoredProcedureMigrationHelper.GetSqlBatchFromEmbeddedResource("myStoredProc.sql");
foreach (var script in scripts)
{
Sql(script);
}
The problem with this is that every time when I update the stored proc, I have to create new sql file, with name convention like "myStroedProc_versionX". Which is working but lose the version control benefit such as show the difference between versions.
Is there a way / different approach to update stored proc with version control in code first?
A more robust and flexible approach could be to use EF database first and to model your database using Sql Server Data Tools (SSDT). By creating Database project in your solution, you could build a dacpac and apply it on SQL Server instance to update your schema to the desired state.
Disclaimer: I'm a product manager at Redgate Software, makers of ReadyRoll
If you have Visual Studio 2017 Enterprise, which ships with ReadyRoll Core edition, you can switch to using SQL-based migrations for your database deployments. This would allow you to include the deployment of your stored procedures alongside your schema changes, while still allowing you to use EF CodeFirst to do your modelling.
You can read more about this approach in the ReadyRoll documentation:
https://documentation.red-gate.com/display/RR1/Tutorial%3A+Entity+Framework+CodeFirst+migrations
Note that the article makes use of the programmable objects feature of ReadyRoll, which is only included in the Pro edition of ReadyRoll. As an alternative, you could script your stored procedures as post-deployment scripts (although this will cause the scripts to run with every deployment, rather than just on each change).
Unfortunately, EF doesn't provide a native solution for that, but I found a solution and I explain it in this post: https://softcadbury.github.io/dotnet/entity-framework/2022/05/10/versionize-stored-procedures-with-entity-framework.html
The idea is to embark the SQL code of your SQL stored procedures in your solution (works also with SQL views or SQL functions) and with a few C# extensions, you can manage them in EF migrations.
Related
I am currently looking at a way to automate the deployment of stored procedure changes as we are running the stored procedure SQL manually on all environments for each release.
The first solution I thought of was using EF Core migrations. Is this the most suitable option or is there a better way?
Some things to consider:
The database related to this repository I am working on is synced with the main database, so there is basically no database management
It does not have any models of its own
The repository is for data analytics and reporting, so it will mostly be read-only
The only items that will change regularly are the Telerik report files and corresponding stored procedures
You didn't say which database you're using, but if it's any variety of Microsoft SQL Server I find SQL Server Data Tools for Visual Studio a good solution for maintaining all database objects, including stored procedures. Deployment to as many targets as you want is straightforward, and based on the tool comparing the current db objects to your project objects.
Visual Studio SSDT
It is well known that perfomance wise, it is recommended to use SQL Server stored procedures instead of inline code. However, I still use inline SQL queries in Visual Studio for various reasons:
The queries can be neatly organized in separate text files (.sql) and in a folder structure.
The files are part of the Visual Studio solution and thus submitted to source control.
Changes to SQL queries can be published together with the applications (using WebDeploy for ASP.NET apps or ClickOnce for Windows apps).
There is no need to synchronize changes to the SQL queries and publishing new versions of applications.
It enables me to work on the SQL queries even when I am offline (or without access to that particular SQL Server).
I am not quite ready to give up these advantages but still, I am aware that I am sacrificing performance.
Is there a way to get the best of both worlds?
Thanks in advance for any insights.
Chris
Literally every single one of your points can be provided by Stored Procedures too... Not only could you just have a .sql file with the CREATE or ALTER command for the stored procedure in the exact same way you manage it now, but you could go a step further and use a SQL Database Project type to deploy them in a better manner...
https://msdn.microsoft.com/en-us/library/xee70aty(v=vs.140).aspx
But I will note that stored procedures are not automatically better for performance... If you read this is probably refered to the fact that they are easier to parameterize, so the plans can be resued. Using proper Parameterized queries you will have the same benefits, so I think the basic premise of your question is incorrect.
I still use inline SQL queries in Visual Studio ...
But how? Context is important here. VS is just a tool. If you use inline queries in your app, then you have a potential security risk if you are not careful about how you implement them (re: sql injection). In addition, the use of inline queries requires the appropriate permissions to database objects - another security risk. And this approach creates a dependency between your code and the schema - which is minimized by using procedures.
In my Application I have used Entity Framework Database First approach.
Currently my application is in Dev Environment, now it need to be moved into Test Environment and later into Production Environment.
So is there anyway that I can use .net feature or Entity framework feature to migrate/create database in Test environment. Other than using SQL feature of restoring the database.
Also note that if any enhancement comes then Database structure can change, table schema can change.
So can you suggest me the best way to easily migrate database schema in different environment without losing existing Data.
If you want to take advantage of EF-Migrations feature, you must convert your application to Code First with Existing Database http://msdn.microsoft.com/en-us/data/jj200620.aspx
If you are unable to convert to code first then you must create the update script by hand.
Use a schema compare tool, compare the development and production server.
For each difference found, create an update query.
Once the entire script is finished, test it on the staging server.
Automating the migration is very risky, it depends on the type and size changes you made to the schema. You can't trust any single feature or tool specially if the changes requires data motion (moving data around).
The following links might help you:
How to do Migrations in DB first approach
EF Migrations for Database-first approach?
With Database First, the easiest way to copy a schema is to extract a data tier application in management studio, create an empty database on the target, register it as a data tier application with the same name, and upgrade the empty database using the upgraded file. You can repeat this step to manage schema changes.
Having said that, going forward you're really better off switching your Database First to Code First as it will make change management across your deployments much easier.
Migrations are best way to deal with it
Preferred way to update production db is to first generate sql file and then run the sql file in production environment.
MS had a very good artical on this
http://msdn.microsoft.com/en-in/data/jj591621.aspx#script
I'm using EntityFramework 6 in VS2013 with database-first. When you pull in the database, you can get stored procedures, which builds methods into your context for each proc, as well as classes for each of the return types which it derives from the procedures.
I'm looking for a way to run this from the command line. The closest I can find is EdmGen, but this apparently does only tables.
I've seen EfGen, but aside from this just being a download from some guy with no source code or peer review, it appears to be at least one version behind.
Building the names and parameters of the methods is easy enough - I could do that myself with the SQL Server metadata - however, building the result classes would be tricker, so ideally I'd like to do whatever VS is doing.
Is there an SDK command or something I can pull from Visual Studio to do this on demand? I often have to re-pull my procs (early in the development process so things are constantly changing), and it's a hassle to do it in the UI.
I don't think what you are trying to do is possible from the command line. As you noticed in the EF6 Designer there is no public API for reverse engineering similar to the one exposed by EdmGen. The lack of the API is not actually the biggest problem here - in general models generated by EdmGen and the new designer are semantically the same - the only difference is that in EF6 two new provider manifest tokens were introduced for SqlServer - 2012 for Sql Server 2012 and 2012.Azure for Sql Azure. You will get these provider manifest tokens when targeting the above databases with the new designer but when using EdmGen you will get 2008. The actual problem here (and the reason why EdmGen does not support generating/importing store functions) is that in the EF provider model there is no way to get the description of the results returned by a store function. To make up for this the designer uses the DDEX provider which is able to return the description of the first result set (now, you also know why the EF Designer does not support stored procedures returning multiple resultsets even though it is supported by the runtime) returned by a store function. Since DDEX is basically a VS thing I don't think you will be able to import store functions from command line using out-of-the-box tooling.
I want to introduce database migrations into my project and would like to be able to generate my initial migration scripts from the database. I was wondering if there are any code generation tools around to do this? I was thinking of using migrator.net but am happy to use anything so long as I can get a tool to generate code for it.
Wizardby can perform reverse-engineering of existing database schema.
Data Dude (ie: Visual Studio Team System Database Edition) does a very, very good job of this. It allows automatic migration code generation through multiple versions, as well as building full scripts off an existing DB.
Fluent Migrator can do this now too
http://computeristsolutions.com/blog/posts/2011/4/dumping-existing-schema-with-fluentmigrator