In my Windows Application project the Microsoft Report Shows an Error Privacy Statement on Client Machine , Not on my Machine
Microsoft Report works on Client Machine very well.
This Error does not shows on Runtime , but after closing the Application this Error appears
after alonge years I found that I must first close the form that contains the Report Viewer before calling the Application.Exit(); method.
because the Report Viewer session still working if I called this method directly without closing the form of Report Viewer and this causes the problem above.
Related
The Problem
I'm using a scheduled task to open an MS Access database, run a macro to email a report in PDF format, and then close the database. The report is relatively basic and the macro simply uses the EmailDatabaseObject action to export & email the report in PDF format.
This has been running successfully on a daily basis for the past 4 years on a Windows 7 machine running the latest version of Office 365 compatible with Windows 7.
I've recently updated the machine to Windows 10 and I'm now encountering a No Current Record error when running the scheduled task. After clicking OK to the error several times, Windows reports that MS Access has stopped working and the application crashes.
If I manually open the database and manually run the macro, everything is successful.
Setup
Windows 10 Pro 20H2 (19042.964) 64-bit
Office 365 Apps for Business 2104 (13929.20296) 32-bit
My Research
I've found this MS KB article describing the issue, however, this reportedly applies to MS Access 2003 & 2007. My report has no grouping, but does contain summations in the report footer. However the suggested solution is not feasible since removing the summations would remove necessary information from the report.
I've found this related question, however, this attributes the cause to accessing the database from OneDrive as opposed to a mapped network drive, whereas I am accessing the database from a mapped network drive.
This looks to be the same issue, but I cannot access the 'solution' at Experts Exchange...
What I've Already Tried
Rolling back Office 365 to an earlier version (version 2101).
Running the Scheduled Task with Highest Privileges - but this results in no access to mapped network drives.
Running the macro from a batch file.
Opening the database from another PC and running the macro from a batch file.
Perform the operations using the AutoExec macro rather than invoking a specific macro by name.
Imported all objects from the database into a new local database.
Exporting the report as a PDF locally using the ExportWithFormatting action.
Using the DoCmd.SendObject method to email the report - this results in MS Access immediately crashing.
Changing the default Windows printer & default report printer to 'Microsoft Print to PDF' to rule out possible printer driver issues.
Current Workaround
I've found that this error only arises when the export format is set to PDF; as such, my current workaround is to export the report to RTF format - but this is obviously not ideal.
Update
I've now systematically removed items from the report until I was able to run the report successfully from the scheduled task.
I removed items until I was left with a single static label in the Report Header and a set of fields in the Report Detail referencing basic numeric & text data from a single table in the database.
Removing the Report Header & Footer resulted in the report running successfully from the scheduled task, and so I determined that the issue must be caused by a setting associated with the Report Header/Footer.
I isolated the issue to the 'Force New Page' setting in the Report Header:
With this set to 'After Section', the report crashes; but if this is set to 'None', the report is successful.
However, when setting this to 'None' in the original report, the report still crashes when run from the Task Scheduler and output to PDF.
Steps to Reproduce the Problem
I've uploaded an incredibly basic database here, containing a single table, a single report, and a single macro which executes the ExportWithFormatting action followed by the QuitAccess action.
To reproduce the problem, open a command prompt window and issue the following commands:
cd C:\Program Files (x86)\Microsoft Office\root\Office16
msaccess.exe C:\YourPath\test.accdb /x macro1
MS Access should then open and you may be presented with the 'No Current Record' error.
Has anyone else encountered this issue and knows of a solution?
Many thanks for your time.
I have recently tried to use Report Viewer Web Part in a SharePoint page. The reports have been used outside SharePoint for years. We are currently on SSRS 2008 R2 native mode and SharePoint 2007. After a while, when you go to the page with the web parts, you just get the error:
The report execution yoty4kmgk3hjr5uup1ng0a45 has expired or cannot be found. (rsExecutionNotFound)
And, in the SSRS log you get:
library!ReportServer_0-33!13bc!10/28/2013-11:09:45:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: , An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.;
session!ReportServer_0-33!13bc!10/28/2013-11:09:45:: e ERROR: Error in getting session data: Invalid or Expired Session: yoty4kmgk3hjr5uup1ng0a45
session!ReportServer_0-33!13bc!10/28/2013-11:09:45:: i INFO: LoadSnapshot: Item with session: yoty4kmgk3hjr5uup1ng0a45, reportPath: , userName: DOMAIN\USER not found in the database
library!ReportServer_0-33!13bc!10/28/2013-11:09:45:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: , Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: The report execution yoty4kmgk3hjr5uup1ng0a45 has expired or cannot be found.;
library!ReportServer_0-33!f84!10/28/2013-11:09:45:: i INFO: RenderForNewSession('/PATH/REPORT')
Now I know exactly what this is. We get this all the time. When you run a report, SSRS takes a temporary snapshot and associates it with your session, and then renders from the snapshot to the browser. If you allow the report to sit open in the browser long enough the session times out and the temporary snapshot is destroyed. If you come back and try to interact with the report you will get this error because the session is gone. When this happens in a browser you can simply go back to the report manager and re-run the report to get a new session and snapshot.
Right now my creative team is working on the SharePoint layout and design. They have been working with at least three different example pages, which each hosts the same two SSRS reports in an instance of a Report Viewer Web Part. The reports do render normally when you initially place them on the page. However, after SSRS expires the session, the web part will show the session not found error. Each page establishes a different session for the same report so there will be multiple sessions open and the report will continue to render on one page after it starts showing the error on another.
The message is absolutely correct, the session does not exist. Sessions are transient, with a timeout of 600 seconds. This is expected behavior. So why is the instance of the web part in the page still holding on to the dead session? If you navigate away from the page and then come back, or you refresh the page, why does the SharePoint Report Viewer Web Part not go execute the report and get a new execution id? Is the web part not intelligent enough to know what's going on? Is there some expectation of the instance lifetime that's not being met?
So the question is: How could we get the SSRS SharePoint Web Part to be well behaved? In the SharePoint context a user should be able to open a page and interact with the content on it, unaware of where the content comes from or how it gets there, the experience should be seamless and transparent. In this case the Web Part is caching the session on the SharePoint server [I guess] so once SSRS kills the session the view in SharePoint just renders an error and we have found no way to refresh it.
Is there a way to solve this?
Try to increase the ssrs timeout. I am facing the same problem as I am using ssrs url in my asp.net web application to generate report. If I leave my page open for some time and come back to it, I get the same error that 'Report execution has expired'. I tried different options including adding &rc:UniqueGuid= newguid to the ssrs url, but of no help.
I have a data driven subscription that renders the report in PDF. SSRS 2012, Win 2008 R2 (on Hyper-V) is used.
I have looked in ExecutionLog3, the shared data sets all successfully refresh, the reports successfully render and are output to the correct folder.
I did read somewhere that when rendering the reports in IE that the user needed permissions to the Temporary Internet Files folder, however I don't know if this is valid for data driven subscriptions? I did add the execution account (a local user) to have read/write permissions on the ReportServer temp internet folder.
Apart from this I have no idea what to look for to troubleshoot this issue? Any suggestions will be welcomed.
EDIT - 2012-11-19
Have found the following unhandled exception error in the ReportServer log:
ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.RenderingObjectModelException: , Microsoft.ReportingServices.ReportProcessing.RenderingObjectModelException: A generic error occurred in GDI+. ---> System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+.
at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams)
at Microsoft.Reporting.Chart.WebForms.Chart.Save(Stream imageStream, ChartImageFormat format)
at Microsoft.ReportingServices.OnDemandReportRendering.ChartMapper.GetImage(ImageType imageType)
--- End of inner exception stack trace ---;
It turns out that the GDI+ drivers needed updating on Windows 2008 R2 Server and is a known issue. If you want to know what version of GDI+ you have then do a file search for gdiplus.dll.
I posted the same question here and got a response saying to update the drivers via a hotfix, which can be found at this link, and it provides the version of the gdiplus.dll that will be installed with the hotfix, so you can compare if there is a version change necessary.
You need to request the hotfix, and an email will be sent to you giving you the download location.
This also solved the issue of images not rendering as well as charts
I have some reports that optionally, redirect to another report.Of course parameters are passed during the redirection. The problem is that in Report Viewer the link that should take the action isn't clickable. This works fine when running from Report Manager.The links do what they're meant to (they link to other reports passing through parameters). When the report is run from the asp application with the report viewer, the links do not work at all.This problem became consistent when Report Viewer was upgraded from version 9 to 10 (to eliminate other problems).What should be done?
Not found what was the real problem.Sure it had to do with the fact that after upgrading Report Viewer from 9 to 10 while Visual Studio version is 2008 in our server.However it was resolved after copy-pasting a "good" cell, which did't cause problems from one report to the problematic ones.Only changing the link redirecting to the other level report was left to do in the copied cell.Now all it is fine.
I am using SSRS 2008 R2 and Report Builder 3.0. I set up a shared data source via the browser (http://myserver/reports/) wherein the "credentials are stored securely in the report server" to use with multiple reports. Testing the connection via the browser works.
Now, I fire up Report Builder 3.0. I start a new report and "Add Data Source". I select the "Use a shared connection", browse to the server, and select the above data source. Click "Test Connection" and all is well.
I then try to "Add Dataset". In the dialog, I select "Use a dataset embedded in my report", I select my data source added above, type in the SQL string and click OK. The "Enter Data Source Credentials" appears. No matter what permutation of valid domain (like the domain admin account and others) or SQL Server (like the 'sa' account) credentials plus checkboxes I use, I get an "Unable to connect to data source".
Security settings on the shared data source allow BUILTIN\administrators and domain\administrator all roles. The data source does work, as some legacy migrated reports run fine. Report Builder says the data source connects okay. But, I cannot create new reports, nor modify existing ones.
Any suggestions?
After much gnashing and wailing seems like Report Builder uses information in definitions in Report Server to then run queries locally by itself, and not through Reporting Services.
My mistaken belief was that when I did something like Refresh Fields when setting up a Dataset, Report Builder was going through Report Services to get the relevant output and/or metadata. This seems to not be the case.
I had defined the connection string of the shared data source as Data Source=(local);Initial Catalog=<database name>. Now, this works when you are in Reporting Services' browser interface, but Report Builder seems to read the connection string and use it for itself. Reporting Services on my local development machine does not have any of the setup on the target server running these reports, so anything I would use will fail.
Changing the connection string to Data Source=<server name>;Initial Catalog=<database name>, instead of localhost, allowed Report Builder to work properly. (RB still popped up "Enter Data Source Credentials". I used my Windows credentials, which is a valid login on the target server.)
To accomplish what you are attempting, it sounds like you will need to use windows integrated security.
According to MSDN stored credentials are not passed to client applications. They are for use only by the report server for things like scheduled reports.
http://msdn.microsoft.com/en-us/library/ms159736.aspx
I can tell you that the prompt "Enter Data Source Credentials" is looking for SQL authentication, not domain accounts.
Outstanding question and answer. I really appreciate your careful description. I had the same problem. In my case the problem was that I was accessing Report Builder from a machine connected to my home office by VPN. I guess because I was outside of the Windows network of the home office, RB couldn't authenticate me. Working with a Remote Desktop connected to a machine at the office allowed me to side-step the problem. Your and #RichShealer's answers reminded me that when running the reports from the browser, they're being served up by an inside server machine. This is not the case when running RB, a desktop app.