I agree that Journaling off is a likely cause.  I just tested you code on 2015.1 and i did not have this problem.

Matt is correct Bock Count has been part of the SQL  Optimizer from the very beginning when we had 2K database blocks.  

In the past this number was an estimate.  Now it is calculated as part of TuneTable.  We did not want to change all our internal structures so we just count the number of 8K blocks on disk and divide by 4.

While for the most part this new feature has improved SQL performance that is not always the case.  Introducing the Outlier value can greatly change the Selectivity of a property as you can see in Matt's example:  Status SELECTIVITY went from .25 to .0333.  This change in selectivity can make this index look better to the optimizer and cause queries to use different plans.  Please test your applications carefully when upgrading from before 2013.1 to a version higher than 2013.1



Attached is an example of what I think is the correct way to do what you want.  I have created 2 classes to map the 2 different globals and then created a third class that is a view that exposes the info from the 2 classes in the way that you want.




You can only have 1 data map in a class.


I strongly recommend you create 2 classes and then write a view to join them together,



So I don't think you class would even compile.  The Data map needs to have all the stored fields in it and it looks like you have something called {sub2} that is not in the Data map, it is just in the index.  If it is an SQL Computed field then the class might compile.


Based on your comments it sounds like you are pretending that the ^SPMRMA global is an index when it is really the data map of a second class.


I don't think this will save you much if any in performance over writing the JOIN.


If you really want to do this I would say that ^SPMRMA should be the data map and then to get VendorName out of ^TBL you can write Retrial Code in the data section or you might be better off using compute code in the property def.  In Data Retrieval code you can only use {L#} so you would need to write some code to get a {VendorNum}  In compute code you would be able to reference {VentorNum}.  Going in this directions you would not have an index map, just the Data Map.


While the above will work, I still don't think it is a great idea.

Does the User you are logging into the portal with have %All?

You could turn on Auditing and enable Privilege violation auditing and see if something shows up there.

did you run $SYSTEM.OBJ.Upgrade() on the namespace?