Hi,
used configuration:
Problem description:
XFM project with features in DGN files and linked data (good old mslink) stored in SQL Server. There are plenty of lookup tables used (not sure whether it's correct term), e.g. in feature table there is "Supplier ID" column and there is a separate table referenced with list of all suppliers with unique IDs and their names.
In Bentley Map these information are displayed correctly, so the supplier is displayed using its name. But when the project is published to i-model, it seems only data from feature table are published and lookup tables are ignored, so substantial part of data become unreadable as "human readable format" is replaced by plenty of IDs.
Is there any configuration or it's Mobile Publisher feature?
With regards,
Jan
Jan,
Inga has produced a test case which replicates the described behavior so no customer data should be required. Although not yet confirmed, the cause of the issue appears to be in Bentley Map and not Bentley Map Mobile Publisher. Please file the requested Service Request so related fix(es) and product update(s) can be prioritized and managed appropriately.
Regards,
Jeff Bielefeld [Bentley]
Hi Jan, Defect #923437 has been filed to track this issue.
Hi Jeff and Inga,
thanks a lot for your effort!
Because it's in V8i and moreover probably in Bentley Map, so I assume there is a low chance there will be updated version released (comparing with a priority of BM CE development).
So now it's a race what will happen sooner ;-)
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
We've confirmed the reported issue requires a fix in Bentley Map and that the Data Browser exhibits the same behavior (e.g. not showing the domain/lookup value). You're correct, our priority is Bentley Map CONNECT Edition development, and Update 1 being released soon, will include MSLINK-ed project support. A new Bentley Map Mobile Publisher update is being released later this year that will include Bentley Map CONNECT Edition support as well.
Since the reported behavior does not occur when SQL Server persistency is used, you may determine data migration is the most immediate solution.
For information, I created service ticket #7000807755 for this issue and asked to link the defect with my account.