With TFS 2013, I've exported some queries to Excel. The "History" column is always blank, but I have confirmed that the work items have history entries.
How can I export so I can actually view the history?
The History field isn’t a supported work item field in Excel.
When Team Foundation publishes work terms to Office Project, the field
data is copies from the work item database to Office Project. For the
field data to be copied correctly, the field type in the work item
database, and the field type in Office Project must be compatible. The
History, Html and PlainText work item field types are not supported.
Related
I want to know is this possible to do in SSIS Salesforce Integration Toolkit.
I have installed microsoft visual studio 2015 with SQL server data tools.
I am trying to download salesforce objects data to local SQL server 2016 database. In which I have excel sheet with two columns object name and fields (separated by comma).
So I used ForEach loop container to iterate over the list from excel sheet. And using row values I generated query string i.e. SOQL query.
I tried to provide dynamically generated SOQL query to salesforce source connection But its not working, salesforce source connection editor not taking the dynamic value instead showing error message as shown in below screenshot.
Kindly provide any valuable suggestions to resolve the issue.
I want to dynamically build SOQL query and provide this to Salesforce connector and retrieve data for all salesforce objects i.e offcourse inside loop container.
For the issue you are getting, can you please try to provide a default value for #[User:Fields] and #[User:Oname] to see if it makes any differences? By doing this, the component can have default fields and entity to initiate the metadata.
We would also like to mention that, since the metadata (columns in the Columns page) is defined in the design-time and cannot be changed dynamically during the runtime, so you cannot just simply change the fields in the SOQL query to update the columns during the runtime. This means that the fields need to be exactly the same for each iteration (i.e. entity).
I am using Visual Studio enterprise 2017 (Version:15.71.1) and SSDT(Version:15.1.61804.210)
and also using TFS to keep my code. In my database project all tables are temporal table.
Now when i am changing column type or column name in TFS , i am not able to build my project so not able to generate publish script.
I am getting error :
Error SQL71609: System-versioned current and history tables do not have matching schemas. Mismatched column:"XXXXX"
Do we have any solution for this ?
Generally you can try explicitly defining the history table, then manually keep the schema of the current and history table in sync.
Reference this thread: Avoid schema mismatch in System-Versioned tables
UPDATE:
As you mentioned the solution which worked for you is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
The solution which worked for me , is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
I'm creating an SSAS cube and I would like to provide friendly names for dimensions, measures, KPIs etc.. So, I created all transactions for all properties in Visual Studio Data Tools.
When I browse my cube in Visual Studio it works well, all properties are translated.
However, if I launch PowerPivot for Excel and trying to import data, no property is translated, It gives me strange names such as [Dimension Name] [Hierachy Name] etc.
Any idea to provide friendly translaed names in Excel ?
You can try the following:
On the Table Import Wizard, where you setup your connection to the SSAS click Advanced.
Change the Locale Identifier setting to the preferred locale.
You can find the locale Ids here, in order to find the Id of the language you used at the translations you made at the cube.
I am looking at a sql server database for a tfs 2010 install and I am trying to find bugs/files logged by date.
Is this information contained in the database?
I see other information such as a view named WorkItemChanges which shows all the stories that have been changed by date.
* Directly querying the collection database is unsupported *
The Tfs{YourProjectCollection} database contains all work items for a specific project collection. They live in the different Work Item tables, since a bug is a specific type of work item.
If your TFS environment is configured for reporting using Report Server, then you can use the Analysis cube or the TFSWarehouse databases to query this kind of information. For work items, a limited set of fields is stored and the same goes for files in source control. You should at least be able to find out which have changed. The following doc describes the warehouse structure: Creating, Customizing and Managing reports for Visual Studio ALM. A quick way to get started is from the Excel Powerpivot reports which are installed to your team project by default if your TFS instance is connected to a Sharepoint server with teh appropriate features enabled.
* You have a number of alternatives *
I suppose that your Visual Studio is currently working, if that's the case then there is no need to use a SQL query to get to the information you're after.
To query all bugs (or other work item types) that have changed between two dates, create a work item query (in Visual Studio) that looks like this:
You can import these into Excel for easy manipulation or further aggregation. And you can even quickly create a Report from that. More information can be found in the Bulk Add or Modify work items in Excel.
To query all files changed between a specific date range, is a little harder. You can quickly get all changesets between two dates using the commandline using tf history $/Project /collection:yourprojectcollectionUri /recursive /version"D2012-10-10~D2013-10-10" this will popup window with all changesets between these dates. You can specify /noprompt /format:detailed to dump all details to the command prompt window.
Alternatively, you can do a folder diff between two dates. This can be done from the UI in the Source Control Explorer. Or from the commandline using tf diff or tf folderdiff
I have a number of reports deployed to a SQL Server 2005 Reporting Services server. They were all developed using the same Report Model (SDML) that references the same Data Source View (DSV) that points to a test database filled with mostly dummy data. Now, I would like to make those reports pull data from the live database with our real data instead. The two databases have exactly the same structure.
It seems to me, that if I could just change the Data Source being referenced in the Data Source View, then I could redeploy the report model, and all the reports based on it would also reference the correct data. I can see in Business Intelligence Development Studio 2005 that there's an option in the Data Source View property list in Design mode to change the Data Source. So I changed the Data Source, thinking that would work. However, when I try to redeploy the report model after changing the Data Source in the Data Source View, I get a number of error messages like this one:
Error 1 The Table property of the Entity 'Address' refers to the Table 'dbo_address', which is not in the primary data source. Events.smdl 0 0
Is there something else I need to be doing here? Something in the Report Model or Data Source View that should be updated? Is there another way to do what I need to?
Edit 1:
I tried changing the datasource of the report model on the server after the reports were deployed, and that seemed to work pretty well. It's not exactly what I wanted to do, but it works. Thanks everyone.
The strategy that has worked best for me is to deploy the "test" shared datasource to the server then edit it via the Report Manager interface to point to the "production" database (changing the connection string). Making sure of course Overwrite Datasources is set to false on deploy.
Also, your database schema must be the same in test as it is in production.
I don't have as much experience with the report models but generally SSRS doesn't like it when you make changes to the datasource and asks you to refresh all the datasets that you have if you do.
Alternatively, just change the datasource definition on the report server itself.
It sounds like you're changing the data source that the dsv references. Instead, why don't you try to change connection string of the data source. Internally the DSV uses GUIDs to identify the various tables and fields, I suspect that by creating a new data source the GUIDs will change and that is why you're seeing these error messages (as the error message is mapping the internally used GUID to it's "friendly name").
The setup I use has an identically named Data Source (.rds) file for each environment, in the same folder the reports are deployed to. It's just a connection string...
My experience has been the same as zalzaw's - if you change the Data Source, you have to refresh all the datasets associated with the report while pointing at the new environment based on the data source changes. It's very tedious - you go to the Data tab for the report in Business Intelligence Development Studio 2005:
Select a Dataset from the dropdown menu
Click the Refresh button (2nd to the right of the Dataset dropdown, icon looks like recycle)
Repeat steps until all datasets have been refreshed.
Make sure that the database(s) (and stored procedures) are in sync. It's all for naught if a table exists in Dev but not in Test or Prod...