I'm using Odata to get a connection to my API. No problem there, connection is working and my query gets the results I'm looking for in the preview UNTIL I click on Close & Load
After clicking on this the result gets loaded into the Excel sheet (I can see this in FIDDLER) and there seems to be the problem as data is just disappearing. I get results for the whole last year from different customers, but some data is just getting lost while loading. There are months of missing data. There is no error in the query as the query is just going into an API endpoint.
So I assume there is something wrong in the settings, but I can't figure out where.
If someone has any suggestions, I'm happy for any help.
So in my case, I saw in Fiddler that there was ONE Error arising at the beginning and then it started like everything was fine.
The problem was that there were unexpected input in one Column.
This fixed my issue:
#"Replaced Errors" = Table.ReplaceErrorValues(Source, {{"Coumn4", null}})
Related
I've created a simple spreadsheet that has 3 worksheets that are utilized in Data Queries & Connections processing. They are accessed in the m code with statements like "Source = Excel.CurrentWorkbook(){[Name="TPCT_Static"]}[Content]")". The results of the processing are ultimately connected to a table in the same workbook. When I execute some simple VBA code (i.e. Selection.ListObject.QueryTable.Refresh BackgroundQuery:=False) to ask for a refresh, all is good -- processing occurs and output table is updated. However, anyone else who uses the spreadsheet and asks for a refresh, via the same macro, gets an error "runtime error 1004 - application defined or object defined error" when it hits the above line of QueryTable.Refresh code.
I've had people run the sheet on their PCs, remote into my PC and try to run it there, and everyone but me gets the error. My mind goes to some kind of permissions issue, but all the data is local in the workbook. There were external SQL queries in the spreadsheet in the past but these were all removed -- really. Everything is now static data held in the workbook.
Any ideas?
Thanks,
Mark
The comment about "Fast Combine" got me thinking. Since most of my work is just for me, I typically set Power Query privacy to "None". Perhaps this was the origin of the issue? So, I reset the level to "Public" and then I started to get an error message when I tried to refresh: "Formula.Firewall: Query 'QueryName' (step 'StepName') references other queries or steps and so may not directly access a data source. Please rebuild this data combination." Resolving this error was clarified by instructions at the following site. "https://www.excelguru.ca/blog/2015/03/11/power-query-errors-please-rebuild-this-data-combination/". It is a very nice write-up. I'm not sure why the privacy level of "None" didn't work for everyone, but after attending to the rebuild, refreshes work for everyone. Thanks to all who read the post, made suggestions and thought about a solution.
Thanks,
Mark
I work in a company that started using VDIs for certain SQAs. We have just noticed that in Microfocus ALM in the VDI only, when anyone tries to print a report through the Document Generator, an error occurs. See first screenshot. If you close this out, it freezes the browser and you have to close. When you try again, you'll get the second error below. In researching these, it seems the first could be caused by a Word incompatibility, which we have checked and ruled out. The second can be caused by files in the path of the TD_80 folder, which we have tried to remove as suggested, but the error persists.
Does anyone know what else might cause this error on the VDIs only?
Details from first error
Details from second error
After submitting a ticket to Micro Focus, they said Report Generator is no longer supported. They pointed us to their documentation on creating reports in the Analysis View module under the Dashboard. This seems to work similarly, but the filtering is a little bit different.
In Excel, I successfully connected to an OData feed from Data.Medicare.gov (the website is https://data.medicare.gov/Hospital-Compare/Healthcare-Associated-Infections-Hospital/77hc-ibv8/data and the endpoint is https://data.medicare.gov/api/odata/v4/77hc-ibv8).
However, now that I'm carefully reviewing and analyzing the data, I see that some of the data rows/records on the website (https://data.medicare.gov/Hospital-Compare/Patient-survey-HCAHPS-Hospital/dgck-syfz/data) are missing from my Excel data, while others are duplicated. After refreshing the data in Excel, some of the previously missing rows appear, while others disappear. The rows that appear, disappear, or duplicate with each refresh seem random.
For example, the record with Hospital Name = "Trinitas Regional Medical Center" and Measure ID = "HAI-1-SIR" is on the website but sometimes appears and then reappears from the Excel data table (__id = "row-6s6r~jx5f.wuje") with each refresh. However, the total number of rows does not change and is equal to the downloadable file.
Not sure if this is due to the large number of rows (>170k) in the data set. The only related discussion I have found is on https://blog.crossjoin.co.uk/2018/05/03/troubleshooting-data-refresh-performance-issues-with-odata-data-sources-in-power-bi-and-excel-using-fiddler/ but don't think this tackles my exact issue.
UPDATE 1:
Socrata, who provides the OData Feed service for this site, responded with the following:
[We] have been able to reproduce this behavior in Excel, but I'm not sure what causes it. However, it does not appear to be an issue with the OData feed itself, as I can consistently access that row via my browser (e.g., https://data.medicare.gov/api/odata/v4/77hc-ibv8('row-6s6r~jx5f.wuje')), so it seems to be related to how Excel is handling the data. Unfortunately, I haven't been able to find much online that explains why this is occurring, so it may be best to reach out to Microsoft Support to determine if they are able to assist with this further.
UPDATE 2:
After extensive troubleshooting and discussion with Microsoft's profession technical support, they (incorrectly) concluded the duplicate records were present in the OData feed. Reaching back out to Socrata support, they took into account my observation that this occurs with large data sets only and were able to suggest a resolution to the issue (see answer posted below).
Socrata Support found the issue and suggested appending a $top parameter to the OData feed URL, which resolved the issue for me:
When you load an OData feed in Excel, Excel automatically paginates through the results in the background as it loads in large datasets, and this loading process is resulting in duplicate records. You can work around this by adding a $top parameter to the OData feed URL with a value that is greater than or equal to the total number of rows in the dataset, which will force Excel to load in all the data in a single request rather than paging through the results. For example, if you input https://data.medicare.gov/api/odata/v4/77hc-ibv8?$top=10000000 in as the URL, this will load in all of the records, and there will not be any duplicates.
Microsoft Office 365 Support confirmed "that adding that $top command does indeed seem to stop the duplicates."
UPDATE:
Although the above $top parameter resolved the issue initially, I started getting the following error message in Excel:
Unable to connect
We encountered an error while trying to connect.
Details: "Microsoft.Mashup.Engine1.Library.Resources.HttpResource: Request failed:
OData Version: 3 and 4, Error: The remote server returned an error: (500) Internal Server Error. (An internal error occurred. Please contact Socrata support, referencing diagnostic code epsfgirt9lxlekyt89oq25x54)
OData Version: 4, Error: The remote server returned an error: (500) Internal Server Error. (An internal error occurred. Please contact Socrata support, referencing diagnostic code 58cf025wln5br4qzw6lcrxh3a)
I therefore reached out to Socrata Support and they responded with the following:
[We are] encountering the same error. I checked with our engineering team, and they said that they actually recently made some updates that likely caused this but also should have fixed the underlying issue. So if you remove "?$top=100000" from the OData URL in Excel and just use https://data.medicare.gov/api/odata/v4/yv7e-xc69, that should work and not return duplicate records like you had seen before. I have tested this on a couple of different assets today, and it does indeed seem to be fixed ... .
I used the regular OData endpoint (https://data.medicare.gov/api/odata/v4/yv7e-xc69) and it loaded without duplicates.
Hello everyone and greetings from Germany!
After searching for quite some time I am at my wits' end and I hope someone can help me.
I try to describe my problem as clear and briefly as possible:
I am building a MS Excel 2010 Workbook that includes several (90+) external connections to SharePoint 2013 Lists & Libraries.
These connections were created by SharePoint's integrated "Export to Excel" function (in the List/Library-Ribbon) and the connection-files were then exported to another SP farm.
(The first "source"-SP-Farm is from the customer, the second is our own intranet)
I have to refresh these connections once per day via an automated macro.
A timer-job will open the workbook at night and execute the "RefreshAllConnections"-macro,
that does a little bit more than just refreshing (such as writing the refresh date and time).
So no user is present when this happens.
And this is where my problem is:
From time to time some of those connections cannot be refreshed.
Excel displays an alert saying (translated from german):
"the following data range could not be updated: owssvr (...)
Do you wish to continue the update?
(OK) / (Cancel)
What I found out so far:
1) It's always the Library that is the problem
2) It's rather random which Library won't update and when
3) The problem fixes itself after some time (that's why I'm guessing this has something to do with the library being used/modified by someone else)
4) While a library is refusing to update, using "Export to Excel" function again will prompt an error once the new worksheet is created and the data is supposed to be filled in
Now here are the odds:
1) The alert always uses the "old/original" connection name that was already changed by me.
2) When I press OK the macro just continues in the next line, no error is thrown whatsoever
3) If I press cancel an Error 1004 occurs (which I can at least catch, so that would be okay).
And here are the probs:
Since this is happening automatically at night, there is no user sitting near by to answer these alerts. So:
1) The macro must automatically answer these alerts with "Cancel" IF they pop-up (and I have NO idea how to do that!)
2) I disable them via "Application.displayAlerts = false
HOWEVER: this will automatically answer them with the default answer, which is "OK".
This however is not throwing an error I could catch, so my macro won't now whether the update acutally worked or not.
Well that's about it. Sorry for the long post and thanks for reading.
Hopefully someone of you has an idea.
EDIT:
Could it be that the automatically by SharePoint generated connections are the problem?
(How) can I build them myself?
Well. I solved it myself.
The answer was stupidly simple:
Instead of refreshing the Connection, I now refresh the corresponding QueryTable via "ActiveSheet.ListObjects(1).QueryTable.Refresh"
If the Connection is not responding, an error is thrown that I can now catch properly.
Ugh, finally!
Upgrading from 8.2 to 8.3 and testing out the new No Data Content functionality. Report looks in order if results are returned. The No Data message does not appear. However if we test the report (pass in parameters expecting no results), we are returned a blank page (pdf, html, excel output). Not even the header or footer appear on the page. And the No Data Content message does not appear as well.
We have very complex reports using Oracle SQL and in most cases the Header content is linked to a SQL statement to render output from the database as well as list the parameters passed in. The issue seems to be related to embedded data objects, i.e. we have a list object embedded within a table object. I've tried stripping out the extra layers with no success thus far.
In 8.2 we used style variables, i.e. RowNumber()=0 or RowNumber() is null to conditionally hide data objects in the body of the report. We've never used any conditions to hide or display the header or the footer and in 8.3 now this seems to be an issue.
This seemed like such a useful enhancement in 8.3 but we haven't gotten it working yet. Any thoughts or suggestions to try?
Thanks for reading this. I appreciate any advice.
Joe
We ran into this same problem when upgrading reports from 8.2 => 8.4. We reported it to Cognos as a bug -- Not sure if they've assigned a bug tracker id to it, but we got the impression it wasn't going to be fixed soon. (Obviously, if it exists in 8.3 and it has been carried forward to the next version, it's not a high priority.)
I'm sorry I don't have an answer at the moment on how to fix it, but I was planning to look into work arounds next week. I'll edit this post with any ideas I come up with.
UPDATE:
Not sure if this is an available feature of 8.3, but in 8.4 there is a new "No Data Contents" property for data containers (lists, blocks, etc.). Setting this value to yes creates two tabs at the top of the page, one for a page to be displayed if data is returned, and another for instances when no records are found. You can customize a message to be displayed using that second page. Pretty cool, actually, but buried in the documentation.
Hope that helps. If you still have problems, check out the Index topic "no data > specify what appears for a data container."
yea it appears that a blank pdf is returned... but in fact the cognos viewer bugs out at the second prompt page if there is no data. Headers and footers and items in which didnt need data to render ... as not showing up as well.
This existed in 8.2 and we were always able to do some sort of work around to get it to atleast show. Seems much more prevalent in 8.3 now.
Id like a solution on this as well! halp! >_<
Edit: seems a slight work around is to create a new report in 8.3 and copy each component starting with queries... then variables.. then objects on the page.. followed by page sets and master detail relationships. in that order for simplicity. Essentially recreating the report from scratch in 8.3 seems to fix the problem.
This works for about 90% of our reports.