Forum Discussion
more location data required?
So I figured out the issue, apparently the field literally has to say Zipcode. Before it worked with a business logical named of Job Zip (referring to the zipcode of the vendor job for my data) But when I fixed my cube's dimension attribute to zipcode and works great now.
I know that makes perfect sense but why did it work with a different name in the preview and then get so specific in the release? Seems like a step backwards.
CJenner you can also click on the field in the Desktop and then click on Modeling->Data Category->Postal code. This will help your model understand the granularity of your geography.
It had nothing to do with the model or granularity, it had to do with the fact it worked in Preview but when they did the release they got specific. So unless you specifically labeled the Dimension attribute, or table attribute, Zipcode instead of say "Zip City" it wouldn't work. That is a big miss. Maybe my business unit doesn't want it called Zipcode or Postal Code. Maybe they want it Zip City. So to me, that's a fail because a true Dimension model (ala Kimball) is based on Business Process and what the business calls it, not what the application wants it to be.
it doesn't matter what you call it if you read and follow my instructions above.
No, I'm not and know you why? Because I shouldn't have to. When I go out to a client I don't want to tell them that they have to do what you suggested when they are considering Tableu, Domo or Microstrategy. Obviously they changed the canvas but it's not good enough. My zipcode field- fyi - is at my most atomic level my my dimensional model based on Kimball princepals. So what value does your solution have? None! You know why? Because 90% of the "BI" Architects and Developers don't know what a true Kimball model looks like. So when I fixed the name, my problem was solved which is what most people would do.
Let me tell you something, most BI software companies are out there saying, you don't need to do anything. Just hook our software up and it will work. Those of us who are true Bi architects know the truth, and what's worse is people I inteview know a tool and don't know the theory behind DW or DM design. You can bet that the design I am hooking up to is pure Kimball.
Your suggestion is actually crap because you clearly have missed the point that this application, which I loved at first, is not ready. I have to go to a client next week and explain to them why there's no drill down, or the fact that OLAP isn't direct connection (and yes it makes a difference, and to the poster who said that who want this feature understand OLAP is a moron and I can give you a reason, email me privately and I'll show you why it's important and not about design or anything of the above) .
In the preview we didn't have to what you said, so ask yourself - why do I need to do that now when I didn't before? Don't change the rules half way through the game and telll me it's my fault.