TFS team project administrator not able to run work item query, when tried through the web browser, page shows the error:
TF401349: An unexpected error has occurred, please verify your request and try again
When tried using Visual Studio 2015, the below error:
TF201072: A user or group could not be found. Verify that the users and groups used in your work item type definition have been added to Team Foundation Server.
Event log in the application server shows the below event error:
System.Data.SqlClient.SqlException (0x80131904): error="600047";%:RebuildCallersViews: Connecting Domain User could not be alidated. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
I am using TFS 2015 update 2.
Note: Same project other users can view normal.
Seems there is something wrong with that user account, although this user is already part of a TFS group, but he still can't access TFS work items. Maybe there is some snag in the TFS identity synch service, and it's usually related to a specific collection.
Attaching and re-attaching the collection will force a refresh of the identity synch data, and will usually resolve this kind issue.
If above is sitll not work.There are also many other articles on the web which help determine the root cause:
You can check whether built-in records were missing in table
TFSIntegration..tblsubscription. Refer to the link below for more
details: A case study on TFS identity replication
Another option is check if the SID of service account is correct.
Replace SID if not, you can refer to this thread for the steps.
Also take a look at the solution of this similar
error:Unable to shelve changes in VS2012 for TFS2010
I'm getting a server error when I try to delete build definitions from a project on the Team Foundation Server 2015 web interface.
The error message that pops up is:
Error(s):
500: 500: error
TFS.WebApi.Exception: 500: error
at k (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/corejs?v=ITI0eYHCCehqqjk6JTyPaR5R793ETLoY2_Lqz191Pyo1:64:375)
at http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/corejs?v=ITI0eYHCCehqqjk6JTyPaR5R793ETLoY2_Lqz191Pyo1:64:2955
at d (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/corejs?v=ITI0eYHCCehqqjk6JTyPaR5R793ETLoY2_Lqz191Pyo1:64:635)
at http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/corejs?v=ITI0eYHCCehqqjk6JTyPaR5R793ETLoY2_Lqz191Pyo1:64:2888
at l (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:8122)
at http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:8348
at t.when (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:3780)
at t.u.promiseDispatch (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:2824)
at http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:1649
at MessagePort.t (http://timeweb:8080/tfs/_static/tfs/Dev14.M102/_scripts/TFS/min/q.js:27:5773)
I also get a similar error when I try to save changes to a build definition.
I'm doing everything with an administrator account on the server.
It's acting like the user has INSERT permission in the database but not DELETE or UPDATE, but I'm not sure if this is the cause and the permissions in the database seem OK (why would they be configured incorrectly after a fresh install?).
I'm using a local SQL Server Express instance. I'm using Windows Authentication for TFS, and I'm able to login with Windows Authentication and manually delete them from the database using SQL Server Management Studio.
I just did another uninstall/fresh install and I'm still seeing this error. Any insight into the cause or solution would be much appreciated.
UPDATE
A SQL Server trace isn't showing any relevant commands being received when I attempt the delete/edit, so it seems like the error is happening before it even reaches out to the database.
First, please make sure you have enough permission. Such as edit build definition . You can use tf permission command to list the realted permission info.
For example: tf permission /user:userID /collection:http://xxx:8080/tfs/defaultcollection
which will return the modified permission for that user under the collection path. Also work with server path.
Also add your user in Team Project Administrator Group and Build Administrator Group.
Try to clean browser cache and close the browser then try it again.
Trying to use OpsHub (free version) to migrate from on-prem TFS to VSTS. It is failing on a work item with the following error:
com.opshub.exceptions.eai.EAITFSPollerException: OpsHub-012310: Error
occurred in getting link/attachment information for WorkItem 46906
Revision 1. Caused By OH-TFS-Connector-0051: Operation failed
getLinkInformation. Server Error : TF26198: The work item does not
exist, or you do not have permission to access it.
I am able to access the work item. I did see the work item had 3 associated work items and I verified I could open all of those as well.
Any suggestions? I did get this with a few other work items and I purged them. I would like to know the cause as I anticipate running into this issue again and the process of manually removing the work items is costly as I do not have a list of all the problem work items. I have to resume the migration and wait for it to error.
Update: I have been able to identify the culprit. This work item is linked to another work item in a different project. Surprisingly I can't see that item even though I have collection admin. I'll keep working on it. I know the linked work item exists.
As Justin confirmed himself, the issue was Access Permission. The user through which the migration was running, could access the WIT in question and it's links. But could not access the linked WIT (which was from another project). Providing the permission to the migration user, by making him the 'Project Collection Administrator' solved the issue.
I am setting up TFS 2012 Express.
I have restored the code into the databases from our previous server and went into the 'Team Project Collections' screen in TFS Server Express Administration Console.
I stopped the collection, edited it and saved it. Now the screen is locked saying "Updating Project Collection Properties". The only way I can stop it is to kill the console in the Task Manager.
However, if I do then when I rerun it the collection cannot be started unless I finish the config. If I open, edit and try resaving it then I get the same progress bar with the caption "Updating Project Collection Properties" which does not ever seem to complete?
I have tried rebooting the PC but that has not changed anything.
Has anyone else seen this?
If the properties don't have to be updated, find this table 'dbo.tbl_ServicingJobDetail' in database 'Tfs_Configuration', then remove the relevant data line which column 'Result' is 'Null'.
Another solution that has not be validated: try to check the user 'NT AUTHORITY\LOCAL SERVICE' on database 'Tfs_Configuration' whether or not to have the correct authority, then restart 'TFSJobAgent' service.
——————————————————Seperator————————————————————
I tried, the first solution above is incorrect, the second is correct, try to check the 'NT AUTHORITY\LOCAL SERVICE' user is addin to the SQL Server instance.
I have got into a bad state with my ASP.Net MVC 5 project, using Code-First Entity Framework. I don't care about losing data, I just want to be able to start fresh, recreate the database and start using Code-First migrations.
Currently I am in a state where every attempt to Update-Database results in an exception being thrown or getting an error message. Also the website can't access the database correctly. How can I wipe all migrations, re-create the database and start from scratch without having to create a new project? In other words, I want to keep my code but drop the database.
Later I will also want to get the deployment database (SQL Server on Azure) in sync. Again, I don't mind dropping all the data - I just want to get it working.
Please provide any how-to steps to get back to a clean state. Much appreciated.
Follow below steps:
1) First go to Server Explorer in Visual Studio, check if the ".mdf" Data Connections for this project are connected, if so, right click and delete.
2 )Go to Solution Explorer, click show All Files icon.
3) Go to App_Data, right click and delete all ".mdf" files for this project.
4) Delete Migrations folder by right click and delete.
5) Go to SQL Server Management Studio, make sure the DB for this project is not there, otherwise delete it.
6) Go to Package Manager Console in Visual Studio and type:
Enable-Migrations -Force
Add-Migration init
Update-Database
7) Run your application
Note: In step 6 part 3, if you get an error "Cannot attach the file...", it is possibly because you didn't delete the database files completely in SQL Server.
I would like to add that Lin's answer is correct.
If you improperly delete the MDF you will have to fix it. To fix the screwed up connections in the project to the MDF. Short answer; recreate and delete it properly.
Create a new MDF and name it the same as the old MDF, put it in the same folder location. You can create a new project and create a new mdf. The mdf does not have to match your old tables, because were going to delete it. So create or copy an old one to the correct folder.
Open it in server explorer [double click the mdf from solution explorer]
Delete it in server explorer
Delete it from solution explorer
run update-database -force [Use force if necessary]
Done, enjoy your new db
UPDATE 11/12/14 - I use this all the time when I make a breaking db change.
I found this is a great way to roll back your migrations to the original db:
Puts the db back to original
Run the normal migration to put it back to current
Update-Database -TargetMigration:0 -force [This will destroy all tables and all data.]
Update-Database -force [use force if necessary]
This worked for me:
Delete database from SQL Server Object Explorer in Visual Studio.
Right-click and select delete.
Delete mdf and ldf files from file system - if they are still there.
Rebuild Solution.
Start Application - database will be re-created.
While this question is premised by not caring about the data, sometimes maintenance of the data is essential.
If so, I wrote a list of steps on how to recover from Entity Framework nightmare when the database already has tables with the same name here: How to recover from Entity Framework nightmare - database already has tables with the same name
Apparently... a moderator saw fit to delete my post so I'll paste it here:
How to recover from Entity Framework nightmare - database already has tables with the same name
Description: If you're like us when your team is new to EF, you'll end up in a state where you either can't create a new local database or you can't apply updates to your production database. You want to get back to a clean EF environment and then stick to basics, but you can't. If you get it working for production, you can't create a local db, and if you get it working for local, your production server gets out of sync. And finally, you don't want to delete any production server data.
Symptom: Can't run Update-Database because it's trying to run the creation script and the database already has tables with the same name.
Error Message: System.Data.SqlClient.SqlException (0x80131904): There
is already an object named '' in the database.
Problem Background: EF understands where the current database is at compared to where the code is at based on a table in the database called dbo.__MigrationHistory. When it looks at the Migration Scripts, it tries to reconsile where it was last at with the scripts. If it can't, it just tries to apply them in order. This means, it goes back to the initial creation script and if you look at the very first part in the UP command, it'll be the CreeateTable for the table that the error was occurring on.
To understand this in more detail, I'd recommend watching both videos referenced here:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Solution: What we need to do is to trick EF into thinking that the current database is up to date while not applying these CreateTable commands. At the same time, we still want those commands to exist so we can create new local databases.
Step 1: Production DB clean
First, make a backup of your production db. In SSMS, Right-Click on the database, Select "Tasks > Export Data-tier application..." and follow the prompts.
Open your production database and delete/drop the dbo.__MigrationHistory table.
Step 2: Local environment clean
Open your migrations folder and delete it. I'm assuming you can get this all back from git if necessary.
Step 3: Recreate Initial
In the Package Manager, run "Enable-Migrations" (EF will prompt you to use -ContextTypeName if you have multiple contexts).
Run "Add-Migration Initial -verbose". This will Create the initial script to create the database from scratch based on the current code.
If you had any seed operations in the previous Configuration.cs, then copy that across.
Step 4: Trick EF
At this point, if we ran Update-Database, we'd be getting the original error. So, we need to trick EF into thinking that it's up to date, without running these commands. So, go into the Up method in the Initial migration you just created and comment it all out.
Step 5: Update-Database
With no code to execute on the Up process, EF will create the dbo.__MigrationHistory table with the correct entry to say that it ran this script correctly. Go and check it out if you like.
Now, uncomment that code and save.
You can run Update-Database again if you want to check that EF thinks its up to date. It won't run the Up step with all of the CreateTable commands because it thinks it's already done this.
Step 6: Confirm EF is ACTUALLY up to date
If you had code that hadn't yet had migrations applied to it, this is what I did...
Run "Add-Migration MissingMigrations"
This will create practically an empty script. Because the code was there already, there was actually the correct commands to create these tables in the initial migration script, so I just cut the CreateTable and equivalent drop commands into the Up and Down methods.
Now, run Update-Database again and watch it execute your new migration script, creating the appropriate tables in the database.
Step 7: Re-confirm and commit.
Build, test, run. Ensure that everything is running then commit the changes.
Step 8: Let the rest of your team know how to proceed.
When the next person updates, EF won't know what hit it given that the scripts it had run before don't exist. But, assuming that local databases can be blown away and re-created, this is all good. They will need to drop their local database and add create it from EF again. If they had local changes and pending migrations, I'd recommend they create their DB again on master, switch to their feature branch and re-create those migration scripts from scratch.
Just want to add to the excellent answer of #Lin:
5) B.
If you don't have SQL Management Studio, go to "SQL Server Object Explorer".
If you cannot see your project db in the localdb "SQL Server Object Explorer", then click on "Add SQL server" button to add it to the list manually. Then you can delete the db from the list.
A possible very simple fix that worked for me. After deleting any database references and connections you find in server/serverobject explorer, right click the App_Data folder (didn't show any objects within the application for me) and select open. Once open put all the database/etc. files in a backup folder or if you have the guts just delete them. Run your application and it should recreate everything from scratch.
My solution is best suited for :
- deleted your mdf file
- want to re-create your db.
In order to recreate your database you need add the connection using Visual Studio.
Step 1 : Go to Server Explorer add new connection( or look for a add db icon).
Step 2 : Change Datasource to Microsoft SQL Server Database File.
Step 3 : add any database name you desire in the Database file name field.(preferably the same name you have in the web.config AttachDbFilename attribute)
Step 4 : click browse and navigate to where you will like it to be located.
Step 5 : in the package manager console run command update-database