I work with MVC code first and I us local DB (DB in app_data file) and I'm single programmer.
In visual studio, I create "develop branch" and change the database in develop.
then I checkout to master.
BUT Database changed for master and master need to "add migration" and "update database"
that's the problem that goes along with every checkout.
as Microsoft says, each branch, need to separate DB.
Can I have separate db for each branch?
notice: I work with local db and I dont have microsoft sql server management
This happens because you have different code bases on both branches. This of course is why you have separated branches on the first place.
Code first controls your database comparing your migrations with __MigrationHistory table, which is automatically created when use are using code first approach.
Even using localDb you could create separate DBs for each branch. You can use Sql Server Object Explorer from within Visual Studio. Create your two databases there, instead of under app_data.
Then for every branch you can have a different connection string in your config file. Same connection string key, but pointing to a different DB.
Related
I have 2 different tfs servers, on different machines. Both of them is not in any domain. Each of them has their own project collections and team projects.
What I wanna do is merge them on a new server. What I believe this is called consolidation.
I have been researching for this job, but documents I have found were a little uncomprehensive for me. But I planned a path afterall. Lets say I have servers A, B, and C. A and B are the old ones, and C will be the new one.
Server A: 2015.4
take full backup of the db via TFS administration console, to \\backups\tfsA
Server B: 2015.4
take full backup of the db via TFS administration console, to \\backups\tfsB
Server C:
install the TFS 2015.4 - do not configure
restore database via TFS administration console, from \\backups\tfsA
restore database via TFS administration console, from \\backups\tfsB
configure TFS
My question here is
"Would this path actually work?", restoration from 2 different paths seems a little scary to me, but can't be sure. Or;
Should I have the db backups on the same path like \\backups\tfsAB and run restore from that path?
After this process is completed, I need to make an environment migration too and have this new tfs work with an Active Directory, but that should be another question after I make this work I guess.
You cannot merge the two servers directly as you mention, as some of the configuration would be in the database for each server.
What you can do is move one Team Project Collection at a time, by detaching it from the old server (will copy needed configuration from the common configuration database into the collection database), make a backup of that particular Team Project Collection database, restore it on the new server and finally attaching it (will copy configuration back to the common configuration database).
You do need to think of the naming as the Team Project Collection needs to have a unique name on the new merged server. Renaming is done by changing the name upon restore.
Question is similar to this question.
I have a database project which uses link servers in several of the views and stored procedures.
According to Microsoft, Visual Studio 2010 database projects do not explicitly support link servers, but you can kind of hack it using References and SQLCMD variables:
http://msdn.microsoft.com/en-us/library/bb386242.aspx
My database (the database itself) has a link server conenction to a Warehouse database. The Warehouse database project is stored in a separate Team Project Collection.
Is there any way to add the Warehouse project as a reference in my project?
The following article explains how to use reference variables in a database project.
http://msdn.microsoft.com/en-us/library/bb386242.aspx
This is necessary when you are referring to a database that is not in the same solution (see the first chart, second row).
In my case, I will probably have separate solutions for each different business environment (internal apps, external apps, warehouse, etc.). Each of these solutions will have several databases. But the databases will need to refer to databases that are not in the same solution (ex., an internal DB might have stored procedures that pull data from an external DB).
In this case, I think the best solution is to refer to the .dbschema file that is generated when the project is built. You can configure a nightly build for each project, and have the build output be copied to a specific shared drive location. You could then point any database project to any other database’s schema by adding a database reference (described in the above article) to the .dbschema ( on the shared drive) for the database.
If you wanted to make it more sophisticated, you could modify the build template to copy the necessary .dbschema files from the build output into each project and check them in.
In the case where the database does not have a project and is not being actively changed, it will be necessary to create a temporary database project for the database so you can build a .dbschema file. The built .dbschema file can then be checked in to the dependent project, and you won’t have to generate it ever again unless it changes.
I’ll do my best at an example…
Problem:
Project ABC depends on the data warehouse, and on project XYZ. Project XYZ is in source control under a different solution, but the Warehouse is not in source control.
Solution:
Create a nightly build for project XYZ
Configure the build output directory to go to a shared drive
Create a custom build template for project ABC that will copy the XYZ.dbschema file in to the ABC project and check it in
In project ABC, right-click on “Database References” and add a reference to XYZ, specifying the XYZ.dbschema file (instead of the XYZ database project, which is outside the solution)
Create the reference variables to the XYZ project (not sure this is necessary…)
Replace references to XYZ in stored procs & views with the reference variables you created in the previous step (not sure this is necessary…)
Now the references in ABC to XYZ should resolve.
Create a new database project (this can be a temporary, throw-away project)
Have it pull the definition from the Warehouse (right click the project and select “Import from database”)
Build the project
Copy the Warehouse.dbschema file from the build output into the ABC project
In project ABC, right-click on “Database References” and add a reference to the Warehouse.dbschema file
Create reference variables for the Warehouse
Replace references to the Warehouse with the reference variables
Now the references in ABC to the Warehouse should resolve.
I don’t know if it will work just like that, but that is the theory. Hope it helps…
I am using SQL Server as a database and TFS 2008 as Source and Version Control. When I create a object in database respectively I will create the object in TFS as a sql file.
I am facing problem like some developers creating object in Database but they are not updating the TFS with the same.
How do I maintain the TFS and Database in sync and if any differences are there, how can I find easily ?
I would propose to only allow developers to add and modify SQL scripts in your TFS system. Then use build automation to execute those scripts against a clean database. That way, you are always 100% sure you can reproduce your database model and content from the items you have stored in TFS.
I have recently moved our TFS 2010 server to new server, I'm trying to create a backup plan but TFS tells me that A backup plan already exists for this Tfs configuration.
How can I overwright the existing backup plan?
Any Ideas?
This is an intresting one. The tool has a feature to prevent multiple backup plans from being created for the same TFS databases (because they might interfere). It works by setting an extended attribute in the TFS Configuration SQL database (called TFS_BACKUP_PLAN_CONTROLLER) that identifies a configured backup plan. You can't configure another backup plan from a different machine. To do it, you will need to delete this extended attribute using SQL Server Management Studio.
You can use the following command to delete the attribute by,
Use Tfs_Configuration
EXEC sp_dropextendedproperty #name = 'TFS_BACKUP_PLAN_CONTROLLER'
HTH.
Cheers, Tarun
is there a (simple) way to move a single TeamProject from one server to another? Including source code, work items, documents, project site...
We don't want to move our server from one machine to another. Just a single project from server A to server B.
You have two options
You can use the TFS to TFS migration tool: Click Here. This doesn't include the WSS project site.
Or you can backup your TFS db and restore on a new TFS instance, then use the TFSDeleteProject.exe tool to remove the projects you don't want.
The latter option is the easiest, but will not merge the backed up projects with any existing projects on the target instance. Existing projects will be lost. WSS sites can also be moved in this manner as well. See How to: Back Up a Team Foundation Server
The TFS to TFS migration tool is obsolete. The features you are looking for is part of TFS Integration Platform.
Goto http://tfsintegration.codeplex.com/ for more info.
In TFS 2010 you can detach the Project Collection database using the TFS Admin Console and then re-attach it to another TFS Server.
http://msdn.microsoft.com/en-us/library/dd936138.aspx
If you want an entire Project Collection to be moved from one TFS server to another:
1) Detach the collection via Admin Console.
2) Backup the Tfs_SomethingCollection database using SSMS, then restore it to the other database server.
3) On the second TFS Admin Console, attach the project collection. It will show up as an available collection to attach just because it has been restored in the second sql server instance.
I did not migrate the Tfs_Configuration database. In my case I was not utilizing reporting services, build services, or sharepoint.
I hadn't installed the second TFS server and was wondering, what options to choose when installing, and if you should install it after or before restoring the migrated DB(it doesn't really matter): Install TFS on the second machine. If TFS and its database instance will be on seperate servers, then choose Advanced configuration and specify the name of the DB server instance. When you have an opportunity to create a DefaultCollection, then opt to skip that step. The install will create a new Tfs_Configuration DB on the new server. Then follow the above steps to migrate the collection DB to the new DB server instance and attach it.
Programmers will need to add the new server to Team Explorer, and hit Change Source Control... twice in a row for each solution. Make sure the local path mappings are correct, and then Bind each solution/project.