OWB Corrupts Discoverer EUL

Question

HI,
I want to put some attention to an issue I encountered using OWB 9.2. The issue occurs when defining a dimension without any levels. If one exports that dimension through the discoverer bridge and imports it in the EUL, the EUL is corrupted. To see it one needs to do a second import, it will generate an error (cyclic hierarchy, eul not changed). The mentioned dimension is NOT visible in discoverer, however it will need either reinstalling the EUL (thus losing all metadata entered and/or changed) or hacking into the EUL to remove the hierarchy which has no levels.
IMO this is a serious problem which needs to be addressed ASAP, however raising an iTAR only resulted in a product enhancement request (IMO way to low for such a problem).
The referenced iTAR ( 3507810.999 ) and product enhancement request ( bug: 3237872) are available for viewing (with proper authorisation).
How to put it "High" on the list of development?
Greetings,
Wilco

Answer 1

Let me explain,
A developper designed the dimension and forgot to add levels.
OWB validated the dimension as OK (This shoul already result in invalid dimension IMO).
We assigned the dimension to a collection, and exported a complete collection through the discoverer bridge. (6 Dimensions an 3 Facts).
Export went successfully.
During Import we got your error also, so we exported again. The then resulting eex imported successfully into OWB.
The dimension we did not use right away, is was part of the 2nd increment of development, but created allready for future need.
When we modified the ETL, because of a missing field, we reexported through the discoverer bridge.
The file we got then we loaded with the following option in Discoverer : refresh the object, preserve display related properties. This reulted in the import not beeing able to finish due to "cyclic hierarchy error", the EUL was not changed. importing the new field was impossible.
We did not want to create the extra field by hand, due to the fact that Discoverer and OWB use uid's, which would get out of sync, resulting in a almost unmaintainable EUL (we have experienced it allready).
If of use, following TAR/bug's are related (from Discoverer and OWB side)
Discoverer
iTAR 3398979.996
BUG none
OWB
iTAR 3507810.999
BUG 3237872
On the side of Discoverer they recognize it as a bug, but also treat it as enhancement, while at the side that realy causes the problems it is treated as a "would be nice to have" feature (in my interpretation)
I am even encouraged to start a discussion on this issue to upgrade the bug. In my opinion it is a bug, and not even a small one. I believe that a product should never be corrupting metadata or functionality of another product.
If one buy's a car, and after your wife has driven it and made a little scratch on the paint (and only teh paint), I believe nobody would accept it if from that moment on, noone would be able to normally drive the car because it is impossible to drive that car around a corner. If one goes to the garage, they will respond with: eeeh, OK we will mention this to the factory, so they can add it as an option. In the mean time buy a new car, and do not make any scratches to the paint.
(You will have to admit the analogy here)
Greetings,
Wilco