When I press refresh button in Power BI (version 2.112.1161.0) I have this error
message
! Table1
A cyclic reference was encountered during evaluation.
! Table2
Loading blocked by failures with other queries.
I always solve it by going to another tab (sheet) and press refresh button and everything's fine. The refresh completes.
Is this error serious? How could I fix it or debug it?
You can go through some definitions for "Cyclic/Circular Reference". You probably created 2 logical columns that are dependent on each other. As for column A, you are using the value from column B. And same for column B, you are using the output of column A. It's a deadlock.
The seriousness depends on your use of data from those columns as they will never give you output. If they are a must for your report, this is serious :) and you have to fix this.
This is a long-standing bug that you can safely ignore. There must be some race condition bug that occasionally causes the PQ engine to fail but as you say, it goes away on its own.
For others reading, this is different to the circular references errors you sometimes get in the vertipaq engine caused by model ambiguity caused by relationships, multiple calculated columns or genuine logical errors and is to do with the PQ engine.
You are not giving us a whole lot to go by. If I read your problem correctly, the initial refresh is the issue, subsequent ones work.
From my perspective, there are two possible issues here:
The software version you are using is buggy, as others have suggested. See also this link, which suggests you could uninstall/reinstall the desktop client you are using. However, just like in the case that post author describes, it seems to present itself as a mere annoyance, nothing that seems worrisome, provided that the results you get are accurate otherwise.
Alternatively, it could be a true circular reference that somehow gets resolved in between, but I doubt that. Here is another link describing circular references in detail.
If this were me, I'd try the uninstall/reinstall and see if that indeed fixes it. Otherwise, I'd probably ignore it.
Try refreshing the data for Table 1 first then refresh all the tables that should resolve the issue.
Related
I have a query that imports two sheets from an xlsx file, combines the data, unpivots it, and does other cleanup steps. For the resulting fact table I also defined relations to 3 further dim tables.
Then I decided to refactor the query in the PowerQuery editor, including splitting the query up into 3 steps and disabling load of the the first two. (To play it safe I also stored my pbix w/o applying the steps.)
But then after a Close & Apply I got the following cryptic error message:
Something went wrong.
Each original name must belong to the set of all names.
PBIDesktop version is 2.96.701.0 64-bit (August 2021)
Searching the web I found people suggesting that the error might be related to specific PBIDesktop versions and that moving back to a previous version would solve the issue.
For me it was easier than that, though a bit mysterious:
In PowerQuery I enabled load for all sub-queries,
let it apply all my steps and the error message was gone.
Then back in PowerQuery I could disable load for the sub-queries w/o triggering the error again!
I hope that this might help someone somewhen.
This error pops up randomly when I import data to Power BI using Supermetrics API about a day after when trying to refresh.
For example, using Adobe Analytics data, when I try to refresh my dashboard a day later, I sometimes get this error, saying
When I click on "Go to error" it takes me to Changed type step, but I see that the code remains the same as I first imported it.
Going to Navigation step, I see that the data has changed, but I don't know why, since I haven't changed anything since I pulled data to Power BI.
What it used to look like:
vs what it looks like now
I have tried seeking help from Microsoft community, but no use, since most topics suggest changes to the code, which I haven't done.
This is 100% an issue in import, and as this issue has only just come up now it is due to a change in source format.
Looking at the breakdown of your imported data, it seems as though you are accessing a web source? This makes me think that the html make-up of that webpage has changed.
Unfortunately, the easiest way of dealing with something like this, is to rebuild the query from the ground up. If you are still struggling, let me know and I will have a look into it further.
Possibly, the 'Date' column is not arriving from the data feed (Supermetrics API) during your refresh. When you come across this issue, read the data feed in other Power BI window or check in the source so that you can confirm, the 'Date' column is missing during a particular point in time.
Thanks.
For me, I found that when my data source changed in terms of column header name, this error was thrown. You probably already sorted it out by now, but any future readers, I would double check the source to make sure no changes were made that might affect this, and then if the source is unchanged in it's version history, then rebuild the inquiry again. It sucks if this is due to a PBI issue, but these two methods should solve 99% of the instances of this error.
I add an image in order to explain myself better.
I have 300 something ports in a expression. I have created the equivalent number of groups in a union. I want each port of this expression to go to a port/field of the Union. One to one relationship. It seems like powercenter is not able to do this with autolink, or at least I'm unable to find the proper way to do this. How could I work arround this issue? Because I've been told that is likely that in a few days it will be more than 700 ports, and the amount it takes to do by hand is quite insane. Thanks in advance.
I'm surprised it validates... union is for homogenous sources but you seem to be trying to pivot your data (in which case I'd suggest using another transformation i.e. a normalizer and Informatica will start behaving as expected)
Possible solution: make a bunch of connections, save and export the file as xml, go to the lines when the connections are done, and replace that zone with as many rows as you need.
What I did specifically was to get the original rows, change the names as appropiate with the help of notepad++ and excel, and then go back to the original file and replace all of it. Check everything three times, and import the file back to powercenter.
I say possible solution because it's messy and dirty, but even though it may lead to mistakes I feel like the amount is vastly inferior and you have the versioning on your side, so just save before exporting. If someone with more experience could tell me it's thoughts about this, it would be a great opportunity to learn, just leaving this in case it goes unanswered
We're using MFC data exchange to validate some data and we're having some problems. We're using the DDV_MinMaxFloat call to ensure that edit boxes in various parts of the application contain floating point numbers within a specified range. When using this validation if a value is entered out of range a dialog is automatically displayed to the user indicating that the value must lie within the range specified. This has been working correctly whilst running the application in debug however when building a release we are getting problems. The validation is still performed in release mode however the message box displayed to the user is blank.
I've tried the usual forcing a rebuild, deleting old resource files and deleting precompiled header files but this continues to happen in release mode. Has anyone come across this before? Are there any obvious things to look for?
I should also add that this application is over 10 years old, so obviously has been working correctly before. Somehow something has gone wrong in the last few weeks to cause this.
Those messages will come from MFC's resource strings. There might be some conflict with your own resources. Check to make sure your resources adhere to Microsoft's guidelines TN020: ID Naming and Numbering Conventions.
Pay particular attention to this bit:
MFC's internal framework implementations reserve two ranges: 0x7000
through 0x7FFF and 0xE000 through 0xEFFF.
Somehow something has gone wrong in the last few weeks to cause this.
Since your application worked fine a few weeks ago, it should be easy: check out the last working version from your revision control system and compare it with the current version. Or try to narrow it down to the first revision which does not work any more.
Check with Spy++ if there are controls on the message box that is displayed and if the text on them is blank, or if there's no controls on them at all. If the text is empty, you'll have to check the resources or the way the messagebox is called/created. Otherwise it may be something like resource being set incorrectly and the message assuming it can read its resource strings from ::AfxGetResourceHandle(). Note that this is a very easy error to make - it's a global handle that can be changed everywhere (including in dll's that you have no control over) so changes in remote parts of the code that at first sight seem unrelated may trigger it.
coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition
I get the above error when attempting to replace a really, really old legacy custom tag with a new custom tag that has some substantial workflow improvements. I only have one idea on how to debug this: comment out different parts of the code (binary search style) until it will compile, narrowing my search until I find the problem code.
Has anyone else ever seen this error before? Any idea what it could possibly be? Contextually, it sounds like I'm trying to use ... something... as a function that isn't defined as a function. That doesn't ring a bell so I'm going to try the binary search idea.
Update: It's running on CF 8.0.1, and doesn't use any <cfscript> blocks at all. Using the binary search of commenting out, I've narrowed it down to a CFThread that starts a background thread that never re-joins the page (by design).
If I comment out the entire contents of the thread, the error goes away (so the cfthread tag itself doesn't appear to have problems on its own...). If I copy the contents of the thread to its own template, that template will compile fine (so the thread contents doesn't appear to have problems on its own...)... so... in theory it should work? I don't know. This is me with my arms up in the air. (WTF?)
I think I've already disproven this idea by un-commenting a small section without the error coming back, but a CFThread should have access to local custom tags that the template creating the thread would have, right? so if there's foo.cfm, it could be accessed from the page as <cf_foo>, and the thread could do the same?
In the last week I've been in contact with the ColdFusion Engineering team at Adobe about this issue and they confirmed for me that this is a bug in ColdFusion.
Specifically, if the number of lines of code inside the thread tag body was too large, it would cause a compile error. The work-around, which I discovered a day or two before I got my answer, is to use a <cfinclude /> to import your thread contents from another file; or to put the code into a method somewhere and call that method from inside the thread body. (Presumably, a custom tag or other clever methods of encapsulation would also work.)
That explains the part of the whole thing that was driving me absolutely insane: that commenting out various parts of the thread body would sometimes make it compile... and now I know it was because enough of the thread body was commented out.
They report that they have fixed the bug, so I assume it will be fixed in the next cumulative hot-fix (if there is one), and in ColdFusion 9.
Since I can't comment yet, Adam, is it really a bug with CF or with the JVM? There's a similar limit on how many lines of code can be compiled within a CFFUNCTION, but the limit is really in the JVM, not the CF tag.
Oooh, that's one I've not seen before.
Depending on what the custom tag does, rather than commenting out different parts, you could try using cfabort - same technique, but only one line to change rather than uncommenting and re-commenting (which can be fiddly and time-consuming).
Also, are you able to test the custom tag in isolation, with completely simplified arguments/etc?
If you're able to post the code, there might be something odd that jumps out at a fresh pair of eyes?
that error usually comes up when you have a function that is set to remote. kinda funny that your getting it with a custom tag though. are you sure that the custom tag doesn't have any functions in it? can you post the code?
Strange that it is a compilation error. If the code base is not too huge I would make sure all variables in the thread and called udfs are explicitly scoped.
Next I would move as much externally referenced data into the thread arguments scope to isolate the interactions with the page.
Finally if that does not clear it up I would try mangling the names of every variable, function and udf the thread accesses a bit with some test prefix just to make sure that you have not hit a bug where one of your vars or funcs is causing a namespace collision in the jvm in the context of the original page.
Tricky problem.
Have you deleted the compiled class files and saved the original source to a new file just in case something weird occurred during a save?
Have you tried reinstalling CF8.01? Maybe some files got corrupted?