HI all
Unsure what does it mean by the following:
The data type 'XM_TYPE_REAL' does not match the expected data type 'XM_TYPE_INT' for the column 'Actual IS Amt (358599)' in table 'Table (358540)', column mask '0x0000000000000008'.
How can i locate the error ?
The new table originally works , however, it goes like this after I update the new set of data.
Thanks
The above "remarking" solved my error as well.
Changing the "type" does not do the trick.
Source of my table was SQL db and the new table was created through:
Hi,
I had the same problem..
I redid the tables (which contain the errors after the creation of the new table) and everything was back to normal.
I hope to help with this
Amy
For those that found this page via google/bing,
I was able to resolve this issue for myself by commenting out the row that was causing the error on my SUMMARIZECOLUMNS() command, let the table successfully build without the column, then un-commented to add the column back.
This built without errors.
My guess is that the column that was being referenced in the DAX command changed somehow after you (or I, in this case) built the DAX table, and that PBI just needs a chance to refresh its structure. For me, it was some changes to the calculated column that was being referenced. Perhaps the OP had some data that PBI didn't quite know what to do with type-wise, which was causing it to break. (maybe it was coming in as an ANY column sometimes, an INT column other times)
This worked.... Thanks!!!
This technique resolved my issue as well! Thanks for the tip.
That's quite interesting! I found the same thing. In my instance I was borrowing from another report and I pasted the DAX to build the table before everything was setup (relationships and dependent tables). I'm 99% this caused my problem, however, commenting out the lines one at a time and then uncommenting them back allowed the table to be recalculated and it worked!
Thanks @v-Sacoc, that was helpful to me and it fixed that nasty message, however it concerns me because it hasn't addressed the root cause. I'm not sure what will happen when this is deployed and people are using it but it inexplicably breaks again!
What is the source for the table? Seems like the immediate fix would be to go into your query and change the type from Whole Number to Decimal but that's just a wild guess.
Join us for a free, hands-on Microsoft workshop led by women trainers for women where you will learn how to build a Dashboard in a Day!
User | Count |
---|---|
125 | |
74 | |
65 | |
53 | |
53 |
User | Count |
---|---|
199 | |
104 | |
88 | |
79 | |
77 |