When I modify the structure of the table in Sql Server ,won't it be automatically reflected in the "Dbml" Layout designer ?Each and every time i have to delete the tables in "dbml' layout designer and drag the table from sql server.
It would be nice if you had the option to "refresh" keeping any local customizations that you've made, but the designer doesn't seem to work that way. You can, however, simply make the same updates (by hand) in the designer that you've made to the table by adding/deleting columns from the generated class in the designer.
If I were you I'd start using SqlMetal. SqlMetal is a command line application used for generating LINQ DataContexts. It can generate dbml's or just a set of classes for you to use in your project (it's pretty customizable). So create a batch file that calls SqlMetal and run it every time you make database changes and your project will always be up to date with the database.
If you don't want to run the batch file every time you update the database you could just run it every time you build your application with a pre-build step.
There are a number of ways to keep the L2S model in sync with the underlying database:
1) Delete the table(s)/classes involved from the designer surface and drag them back from the 'server explorer' thing.
...or...
2) Update the classes involved manually in the L2S designer.
...or...
3) Use third party tools with update capability (one such tool is my add-in: http://www.huagati.com/dbmltools/ , also mentioned in the Dec 2009 issue of MSDN magazine http://msdn.microsoft.com/en-us/magazine/ee819138.aspx)
...or...
4) Regenerate the entire DBML file using either the designer or sqlmetal.exe.
Related
I'm kinda new to this kind of problem. I'm developing a web-app and changing DB design trying to improve it and add new tables.
well since we had not published the app since some days ago,
what I would do was to dump all the tables in server and import my local version but now we've passed the version 1 and users are starting to use it.
so I can't dump the server, but I still would need to update design of server DB when I want to publish a new version. What are the best practices here?
I like to know how I can manage differences between local and server in mysql?
I need to preserve data in server and just change the design, data on local DB are only for test.
Before this all my other apps were small and I would change a single table or column but I can't keep track of all changes now, since I might revert many of them later and managing all team members on this is impossible.
Assuming you are not using a framework that provides a migration tool for database, you need to keep track of the changes manually.
Create a folder sql_upgrades (or whatever name you name) in your code repository
Whenever a team member updates the SQL schema, he creates a file in this folder with the corresponding ALTER statements, and possibly UPDATE, CREATE TABLE etc. So basically the file contains all the statements used to update the dev database.
Name the files so that it's easy to manage, and that statements for the same feature are grouped together. I suggest something like YYYYMMDD-description.sql, e.g. 20150825-queries-for-feature-foobar.sql
When you push to production, execute the files to upgrade you SQL schema in production. Only execute the files that have been created since your last deployment, and execute them in the order they have been created.
Should you need to rollback a file, check the queries it contains, and write queries to undo what was done (drop added columns, re-create dropped columns, etc.). Note that this is "non-trivial", as many changes cannot be rolled back fully (e.g. you can recreate a dropped column, but you will have lost the data inside).
Many web frameworks (such as Ruby of Rails) have tools that will do exactly that process for you. They usually work together with the ORM provided by the framework. Keeping track of the changes manually in SQL works just as well.
What options exists to manage database scripts and do a new development for database:
For example, the database used by a number of applications and there are a number of developers working with database, what will be the best options to maintain database up to date with the last changes and what should be the process of deployment changes to production
I see two options:
Microsoft visual studio has a database project, so all database
scripts should be add in the project and database can be rebuild
from visual studio
Restore database from backup and apply only new scripts to database
What another options exists? How can I manage database development, what is the best practices? what will be advantages and disadvantages of options I write above? How to maintain new sql scripts?
I understand then source control system should be used, but with DB scripts it's not so easy as with application.
I believe it will be no universal solution, but at least I am interesting in DB developers opinion how it's implemented in your company.
Liquibase is IMHO the best tool. It's brutally simple in its approach, which is one of the reasons it works so well.
You can read up on the site how it works, but basically it creates and manages a simple table that stores a hash of each script to determine if it has run a script yet or not. There's pre- and post- sql too, and you can bypass on conditions... it does pretty much everything you'd want or need. It also has maven integration, so it can seamlessly become part of your build.
I used it very successfully on a large (8 developers) project and now I wouldn't use anything else.
And it's free!
Currently we use SVN and have an "UpgradeScripts" folder where all developers commit their scripts to.
Each script has a generated prefix in the format upg_yyyymmddhhmmss_ScriptName.sql - So when they are deployed they run in a pre-defined order; keeping the database consistent.
This is generated through the below SQL and enforced through a pre commit hook:
select 'upg_' + convert(varchar, SYSUTCDATETIME(), 112)
+ replace(convert(varchar, SYSUTCDATETIME(), 8), ':', '')
+ '-'
+ 'MeaningfulScriptName'
Another handy technique we use is making sure the difference between static and non-static data is clear; so in our database there is the standard "dbo" schema - which indicates non-static data which may change between environments, and a "static" schema. All tables in this schema have static id's, so developers know they can use them in enums and reference the id's in scripts.
If you are looking for something more formal, Red Gate have a utility called SQL Source Control.
Or you could look into using the Data Tier Application framework.
We use DBGhost to version control the database. The scripts to create the current database are stored in TFS (along with the source code) and then DBGhost is used to generate a delta script to upgrade an environment to the current version. DBGhost can also create delta scripts for any static/reference/code data.
It requires a mind shift from the traditional method but is a fantastic solution which I cannot recommend enough. Whilst it is a 3rd party product it fits seamlessly into our automated build and deployment process.
We are possibly looking at switching our tables, for views in EF 4.3.1.
We are using db first via the edmx file, so it generates our entities and dbcontext.
Has anyone got any tips for remapping our entities from tables to views?
Is this prone to disaster? We've had trouble with updating the edmx file in the past via the designer where the underlying changes weren't reflected deep somewhere within the code and we ended up with missing columns.
Or will views act very similar to tables in the EF world?
Designer handles views in completely different way - first of all all views used by EF through designer are read only unless you map stored procedures or custom SQL commands to insert, update and delete operation for each entity you want to modify.
Normally if you have updatable view you can simply modify SSDL part of EDMX and cheat it to pretend that the view is actually a table but this has two consequences:
You must modify EDMX directly as XML
You must not use Update from database any more because it always deletes whole SSDL part and creates a new one without your changes = you must maintain your EDMX manually or buy some extension for VS which will allow you updating only selected tables.
I've perused the threads here on migration from SQL 2000 to SQL 2008 but haven't really run into my question, so here we go with another one.
I'm building a strategy to move specific SQL 2000 databases to a new SQL 2008 R2 instance. My question comes with regards to the best method for transferring the schema and data. One way I know of is to do the quick 'n' dirty detach - copy - attach method, which should work so long as I've done my homework wrt compatibility and code and such.
What if, though, I wrote the schema and logins via script and then copied the data via SSIS? I'm thinking of trying that so I can more easily integrate some of my test cases into the package (error handling and whatnot). What would I be setting myself up for if I did this?
Since you are moving the data between servers or instances, I would recommend moving the data via data flows. If you don't expect to run the code more than once, then you can let the wizard generate your code for this move. However, when I did this once 2+ years ago, the wizard code generated combined execute sql tasks that combined many "create table" commands into one task and created a few data flow tasks that had multiple source and destinations in them to insert data in the destination. This was good to get up and running, but it was inadequate when I wanted to refresh the tables one more time after I modified the schema of the new target tables. If you expect to run the refresh more than once, then you may want to take the time to create the target schema first and then manually create the data flows.
Once you have moved the data, then you can enable full-text search on the new server. I don't believe you will need to have this enabled on your first load.
One reason I recommend against the detach-attach method for migration is that you bring all the dirty laundry from the 2000 database to the 2008 R2 database. If you had too lax security on the 2000 server or many ancient users that shouldn't exist, it could be easier to clean this up by starting from scratch. If you use the detach-attach method, then you have to worry about users.
I am about to use linqtosql in my first asp.net mvc application.
I have come up with a database schema. But the problem is that I may change few of the tables in future. So keeping the model classes in sync with database will be a issue.
I got this link which states the similar situation,
keep LinqToSQL sync with the database
My question is, has any body used the third party tools given in the above post,
do they work properly
www.huagati.com/dbmltools/
www.perpetuumsoft.com/Product.aspx?lang=en&pid=55&tid=linqtosqlsynchronization
Or is there any better approach for this problem.
The "official" approach is to simply delete any out of date tables from the designer then drag the updated table from your Server Navigator back on again. I've been using this method for well over a year now and so long as you make your data context changes at the same time you're updating the database you should be OK. It also gives you extra incentive to make sure you have your database structure in order before continuing.
There is also SQLMetal.
http://msdn.microsoft.com/en-us/library/bb386987.aspx
This is whats in our CreateDBML.bat file
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86
sqlmetal /server:{server-name} /user:{username} /password:{password} /database:{databasename}
/dbml:..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.dbml
/namespace:CompanyName.ProjectName.Domain.Entities /pluralize /views
sqlmetal /code:..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.designer.cs ..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.dbml
pause