I have an ASP.NET MVC 3 application using an Entity Framework (4.3.1) Code First database. Now I would like to create a comprehensive zip file containing the database, the application package generated by Visual Studio 2010 and a script to deploy everything to a Windows 2008 server with IIS7 and SQL Server 2008 with a prepared (but empty) database.
I don't foresee any problems with the deployment of the application package, but I'm unsure of what approach to use in deploying the database. The target environment already has an empty database that's been assigned to me, but I've been told that dropping and creating the database is fine.
From what I've read, I can do a straightforward copy of the .mdf and .ldf files to the server and then setup my connection string to point to that specific file but this approach sort of ignores the database that has already been created (or at least named) for me. The other approach would be to use the the existing .mdf to create the database on the server with a script. My only issue here is that I would like to keep the database name assigned to me.
I usually connect to my development database locally using SQL Management Studio and right-click the database, choose Tasks -> Generate Scripts. Then I select the entire database or just the tables I'd like to keep, click next, then click the Advanced button and make sure that I am scripting out "Schema and Data", and then generate a sql script that I can run on the production database, therefore keeping the table structure and the data that was in the dev database. Obviously, if you don't want to keep the data then just script out the Schema only. Then, point your application's connection string to the new production environment database and you're good to go.
Related
I have been building my ASP.NET Core MVC web application since last year and there are currently 100 migration files in my project, as the database has evolved along with features and capabilities. My development / test database is obviously in sync with this migration.
Now, the time has come to create a Production environment, and I want to have an empty database with only the table schema. So, I just can't copy my test database to create a production database.
So, the question / dilemma I have regarding creating this Production database is as follows;
1. I can either create my Production database by running Add-Migration command (for which I need to delete existing migration files from the project), or
2. Create table schema in SQL Management Server, and keeping the __EFMigrationsHistory from test database
With [1], I am not sure how I will be able to manage my test database with this same project, going forward.
With [2], I am not sure if there is any drawback.
So, what is the standard or best practice for Production deployment?
You can certainly use Visual Studio to create or update database tables, but this would normally just be in your development environment.
If you are worried about the number of migrations you have, you still have the option of starting over by deleting them, and deleting your migration history (and manually deleting your tables and data) and creating a fresh 'Initial create' migration. If you do this you will probably want to export any test or config data first, or make sure you have a way to recreate it.
For the staging and production deployments, best to use SQL Server Management Studio to generate a script to build your tables. The database administrator - or you if it's just you - can create the database and run the script to generate the tables.
This is because staging and production environments tend to be more tightly controlled than development, so best to understand the processes that are most appropriate for the environment.
You need to check that your dev and staging/production SQL databases are set at a matching 'compatibility level', and also need to decide whether you need to add any seed or configuration data on create.
In SQL Server Management Studio, select the appropriate option to generate a script for the required tables.
https://learn.microsoft.com/en-us/sql/ssms/scripting/generate-scripts-sql-server-management-studio?view=sql-server-ver15
You can also use this process to export, and import data - this is ideal for config or test data.
https://dzone.com/articles/generate-database-scripts-with-data-in-sql-server
I have created an application with internal database LightSwitch..
Now I want to publish my application and I want to publish also data of my internal database..How can I do?
for example : I have an application Fantacalcio and I created some players in my internal database of lightswitch..now when I publish my application and I install it in my pc there are no data in my application.. I want that when I install my application there must be players that I have created before..
You can do it programmatically in something like Application_Initialize, or in a SQL script.
LS has no "built-in" way to pre-populate data, so it's a matter of choosing a workaround.
One possible way is to do the following:
Attach the lightswitch internal database to SQL server
Export all the data into a SQL script, here are the instructions
After you have the sql script (mostly INSERT statements), then run
the script on your designated database.
The exact same data should now be populated there.
In our legacy SW we make our own wrapper classes to perform DB command and query. Now we want to switch to .NET 4 and want to use LINQ to SQL. But I am not quite sure whether it is mandatory to add a .mdf file to make it work.
Because we have our database service running already, and we would like to keep using the database on it(because our customers would want to keep using their databases), obviously we don't want to distribute a brand-new database file with our SW. But every article I found about LINQ to SQL says that I need to add a .mdf file to the project to make it work. So how should we do that? Can we use LINQ without assigning any database in the development?
Thanks!
LINQ to SQL doesn't require a local .MDF file in a project to work. You can generate LINQ to SQL classes against an existing remote database. Just connect to the server in the Server Explorer and drag tables to the LINQ to SQL designer.
Many people use the .MDF file in examples simply because it's a small, self-contained database. It's a convenience to the demo, not a requirement.
Additionally, it's possible to create a .MDF file with a schema that matches a remote database and work against that file during development but simply switch connection strings to go from a local file to a remote database.
I've installed VS2010 Express and all associated SQL. I've got an instance running on my local machines of .\sqlexpress and I can connect to it with SSMS. I've created some tables etc.
I want to use Linq to SQL so I have created a new empty .dbml file in my solution. I assume the next step is to connect to the database, but I don't know how as I've never done this before.
I tried Add Connection as it suggests, and the Data Source I can choose Access Database, SQL Server Compact 3.5 or SQL Server Database File.
The Database File one says, "use it to connect to a local instance", so I click that. Then it asks for a database file name, new or existing. Surely I should be typing in the instance name not doing this file thing? If I do type something in, it crease a .mdf in my documents folder and it doesn't really help me much.
Any ideas how I can get this to work?
it's easier than you think.
you create a new database in SQL Management Studio, you call it
whatever, myDatabase...
from Visual Studio you select the SQL Provider and you select the
local instance and the myDatabase as db name.
everything is basically as you said except that you should have created a database and you should then select it in VS.
doing this from a new EF model, VS will store the connection string compatible with EF format in the app.config so you will be able to check it and see how such connection string is written.
I finally figured this out via a blog post or two somewhere online. With the express edition, the option to connect to a local database in the normal way via IP or ./sqlexpress is not present. You have to connect using a File, by finding the .mdf file on your hard disk (within the SQL server folder somewhere) that represents your database, and selecting it.
I have no idea what happens if you update your database schema in SSMS, or why they've restricted it to this bizarre method, but it works and I have been able to query my database.
I'm a bit new to database projects, but I find that with a bigger team it is a good way to synchronize development.
I had a single Database Project that contained all the tables used by a web app.
The powers that be want to display data from another database in the web app.
I create another Database Project that represents the tables I need in the other database.
I create views in the original database that represent tables in the second database (for linq to sql joins mainly)
Questions
Do I create a Sql Server 2008 Server Project and merge both of these databases into it? From what I can tell, a Server Project still only represents a single database.
If a Server Project isn't meant to represent multiple databases, what is it for?
I have added steps in our TFS Workflow to deploy changes from the first Database Project into our Dev environment on check-in (CI). Assuming a Server Project is meant to contain multiple database projects, can I deploy it and have it deploy changes in both databases?
Thanks!
A server project is for server scope objects needed by your solution: endpoints, server principals (logins), server level permissions, linked servers and other similar constructs that are not scoped to any particular database.
Seems to me that what you need is a solution with two projects:
your original database project
you reference database project
You need a third project in this solution, a server project, only if you must add server scoped objects.
For more details, see Using References in Database Projects.