We’re creating some simple reports in SSRS that are being exported via Web Archive (MHTML) and pasted and sent by emails to the relevant subscribers.
These are mainly high level financial reports for the management.
My problem is when the data is exported from the report and pasted in the mail, the layout doesn’t look as good as in the report itself.
For example,
The pasted report data looks like:
December 13, 2010 (12:00:00 A.M. - 11:59:59 P.M.)
Total Video Revenues
$0.00
Completed Sessions
0
Non – completed Sessions
0
Cancelation
0
Instead of looking like:
December 13, 2010 (12:00:00 A.M. - 11:59:59 P.M.)
Total Video Revenues $0.00
Completed Sessions 0
Non – completed Sessions 0
Cancelation 0
The only way I’ve managed to overcome this layout issue is by adding a header into the RDL layout and insert in the header a text box filled with WHITE text (which isn’t visible).
This fixes the issue and the report looks good in the mail.
What can I do ?
I believe that it’s a weird way to solve the issue…
Thanks in advance,
Roni Vered.
Found the solution.
It appears that is a known issue which was fixed in one of the cumulative package updates of sp2.
http://support.microsoft.com/kb/935399.
A table in a report that is delivered by SQL Server 2005 Reporting Services with Service Pack 2 appears to be compressed when the report is opened in Outlook 2007
Related
In the microsoft office store partner center the "Analyze -> Acquisitions" graph for my outlook add-in is not updated for the last 10 days. It looks like it correlates with the day where I uploaded a new version of the add-in which was rejected by the seller dashboard team. But the old version is still available in the office store, so I would expect to see acquisitions for the add-in.
The add-in is named Plandisc, and I have been running e-mail marketing campaigns this week, so I would expect some acquisitions, and not zero as the graph shows.
Metrics run on a standard SLA of 4 days behind the current date.
Any issues with individual metrics should be reported to Support Team via the App Analytics and Commerece option
JIRA tracking issues by creating reports. It shows total estimate of the project, how many time have been taken by a project. What should be the outcome of the project?
Now my question is: What are the types of reports which have been generated in JIRA.
We can generate following reports in JIRA:
1) Average Age Report:
It shows that how many issues are pending or unsolved. Accordingly it will generate a report and give you the particular picture of the project about pending issues.
2) Issue Created vs. Resolved Issues Report:
By the name we can understand that it will create reports for created issues and resolved issues report which will display whole the scenario of the project and display the work done by the Team.
3) Pie chart Report:
It will display issues status with different colors so we can identify the project status or sprint status easily.
4) Project Pivot Report:
It shows that how much time has been taken by the users for verifying project for the specific period?
5) Recently Created issue Report:
It will display all the detail for recently created issues which shows that how many percentage of the project is completed and how many project is pending.
6) All the dead line of the project have been followed or not, all the issues are solved or it has in progress status this all can be verified by reports.
7) We can create sprint report, Epic Report, Version Report, velocity chart, control chart, cumulative flow diagram too.
Progress Report has been shown from here:
Blue line indicates ideal task remaining and red line indicates actual task remaining.
With the help of Pie chart we can see that different status have been displayed with different colors:
8) It also gives reports of Project status or Sprint status.
1) Average Age Report — Shows the average age (in days) of unresolved issues.
2) Created vs Resolved Issues Report — Shows the number of issues created vs the number of issues resolved over a given period of time.
3) Pie Chart Report — Shows the search results from a specified issue filter (or project) in a pie-chart, based on a statistic of your choice.
4) Resolution Time Report — Shows the average time taken to resolve issues.
5) Recently Created Issues Report — Shows the rate at which issues are being created.
6) Single Level Group By Report — Shows the search results from an issue filter, grouped by a field of your choice.
7) Time Since Issues Report — Shows the number of issues for which your chosen date field (e.g. 'Created') was set on a given date.
8) Time Tracking Report – Shows time to track information on issues for a particular version of a project.
9) User Workload Report * — Shows how much work a user has been allocated, and how long it should take.
10) Version Time Tracking Report * — Shows progress towards completing a given version, based on issues' work logs and time estimates.
11) Version Workload Report * — Shows how much outstanding work there is (per user and per issue) before a given version is complete.
12) Workload Pie Chart Report * — Shows the relative workload for assignees of all issues in a particular project or issue filter.
My organisation recently applied an update to TFS 2015 (14.102.25423.0 according to the 'About' page of the web interface) that resulted in the 'My Work' tab in Visual Studio 2015 taking up to one minute to populate. I played around with the queries and managed to narrow the problem down to population of the 'Incoming Requests' section of that tab. Under the hood, this is executing the following WIQL query.
SELECT [System.Id], [System.Links.LinkType], [System.Title], [System.State], [System.Reason], [System.AssignedTo]
FROM WorkItemLinks
WHERE (Source.[System.TeamProject] = #project and Source.[System.WorkItemType] in group 'Microsoft.CodeReviewRequestCategory' and Source.[System.AssignedTo] <> #me and Source.[Microsoft.VSTS.Common.StateCode] <> '1')
and ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
and (Target.[System.WorkItemType] in group 'Microsoft.CodeReviewResponseCategory' and (Target.[System.AssignedTo] = #me or Target.[Microsoft.VSTS.Common.ReviewedBy] = #me) and Target.[Microsoft.VSTS.Common.StateCode] <> '2')
ORDER BY [System.CreatedDate] desc, [System.Id] mode(MustContain)
I've reproduced the slowness using the TFS REST API described in https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql (passing the WIQL query above in the body of the POST request).
The following code review selectors are slow to populate: My Code Reviews & Requests, Incoming Requests.
The following code review selectors are fast to populate: My Code Reviews, Recently Finished, Recently Closed.
The problem is occurring for all users, not just my user.
No one on the team has more than a few code reviews open at any one time.
The problem started occurring practically overnight i.e. on Friday the queries were completing in a second or so, on Monday the queries were taking up to a minute.
Our TFS environment is hosted on Windows Server 2012 (non-R2).
Our TFS environment is backed by SQL Server 2012, SP3 (11.0.6020).
The upgrade to TFS2015.3 was completed as per Microsoft instructions and no issues were encountered and there are no messages in the logs to indicate anything is wrong.
Does anybody have any suggestions about what might be causing this slowness and what can be checked in order to narrow the performance problem down further?
The Team Explorer in Visual Studio provides a dropdown selector for specifying which state of code reviews one wants to list. The available choices are:
My Code Reviews and Requests (open)
My Code Reviews (open/mine)
Incoming Requests (open/others)
Recently Closed (closed)
Recently Finished (finished)
( Annotated each entry above with the state and ownership for clarity.)
According to the description of your performance issue, since this is occurring for all users, seems there are a large number of code reviews in your team. When you open the My work tab , the loading of the various code reviews cause a performance issue.
For this situation, you can try this workaroud: switch over to my code reviews in that Team Explorer drop down selector. After this, please double check whether the issue is gone or still exist.
Answering my own question here... My organisation ended up escalating this through Microsoft and eventually found that there was an issue with out of date statistics causing bad query plan generation. The query that was used to retrieve code review details was taking more than 60 seconds each time it was run.
The queries below will most likely make a significant different to performance if you encounter the same problem.
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCoreLatest] WITH FULLSCAN
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCustomLatest] WITH FULLSCAN
For reference, there's a duplicate of my original post on Microsoft Connect here: https://connect.microsoft.com/VisualStudio/Feedback/Details/3107261. The comments from Microsoft in this post indicate a number of people were seeing similar behaviour.
We're using an Access application that stores and retrieves information from SharePoint, and the times and dates get viewed through the 'filter' of the Time Zone settings on SharePoint.
This has started to cause a problem when just trying to enter a date with no time. People marked as CST will see 7/1/2014 0:00, but those in PST will see 6/30/2014 22:00. Calculations that organise metrics by date would then show the same entry in June for PST users and July for CST.
Is there a way to adjust for this? I don't WANT to be capturing a time in this field, but since it's a Date/Time field on SharePoint, it's attaching a time anyway. Would changing the field in question to 'String' work or would that cause more problems than a more adaptive solution?
(I've read links that popped up in 'Questions that may already have your answer', conducted other searches on and off Stack.)
After a bit of testing after all my Users went home except for one, I found that just changing the type on SharePoint for the fields in question from 'Date/Time' to 'Text (Single Line)' worked perfectly. My Tester had no issues with the VB used to store information and bringing up the raw tables showed the 'proper' date stamps after a restart of the client database.
It seems a little too good to be true, but it appears to be a victory! I'll definitely come back here with an update if anything blows up.
So I have a document library with date, alert and alert-date fields.
The date and alert fields are completed when a doc is uploaded, and there is a workflow which takes the alert away from the date (and also takes an extra day off) and sets it as the alert-date. E.g. If the date is 15/07/2013, and the alert is 1 month, the workflow sets the alert-date to 14/06/013 (15/07/2013 - 1 month and a day). The alerts have options of 1 month, 3 months, 6 months or 1 year. A extra day is always taken off as these workflows are triggered by information management policy which only allows conditions of +1 day (the day is taken away via the workflow and then added via information management policy).
The problem comes when a .docx file is uploaded, as all the alert-dates (even if they relating date and alert aren't populated) are set to 01/01/1900.
I know SharePoint workflows pretty well and have never come across this problem before, so was just wandering if anyone else has and knows a solutions?
Thanks,
Josh.
Found a solution:
The alert-date fields didn't seem to be set at the same time that the workflow was looking them up (for docx files). So I added a minute pause at the beginning of the workflow which gave enough time for all the dates to be set and then for the workflow to look them up, and there are now no issues.
Thanks,
Josh.