Here is an odd thing in 10.2.300 – If you add any table InvcDtl, Part, Order and add the SysRevID – works fine… then you make that a InnerSubQuery, and make a new TopLevel SubQuery… then it doesn’t like it… only SysRevID… it hates being wrapped in 10.2
When a Table is Wrapped in a Sub-Query the SysRevID Column no longer works. Only in BAQ Designer. Known Bug?
Well, now this bug is known.
It is there for years.
I will report the issue, despite the wondering why you need SysRevID field content in your query output…
It works fine in 10.1.500.46 
I don’t need it anymore… I used it in a custom UD100 Screen where they Print Custom “Labels” by pulling in Details from Invoice… Then If the open the record tomorrow I check if the Last Known SysRevID (which I store in UD100) != InvcDtl.SysRevID then the “Record” changed or something changed, then I trigger a “Re-Sync” or a “Let’s make sure the data we have pending to be printed is still the same”.
But instead of Auto-Syncing I’ve trained the User to “Delete” and Re-Import the Record if it has changed and they have not yet processed it. It was shorter than checking all 30 fields for changes.
@Dmitry_Kashulin
On another note you can no longer use the Ice.Sys* Tables in 10.2.300 – the columns come in blank for:
This may be probably by Design; Because there are other Aliases we should be using such as Erp.Company, Erp.UserFile… unfortunately those dont have all the columns.
It seems to be because 10.2.300 adds “zf.SystemCode = it.TableOwner” to its Query, which those Sys tables fail.
You might wonder which Columns one could need from Ice.SysCompany
SMTP or DefaultLabelPrinter seem to be used by folks, when they create their own “BarTender” Auto-Print like UD01.
I still got it to work by adding the Column in a Calculated Field and just hardcoding the Ice.Table.Column in the JOINs.
I suspect this is yet another reason to kill Multi-Tenant which is what I believe why the change was made - for security reasons when sharing a database among several companies.
This restriction has bled into Public Cloud and now On Prem. 
Agreed, as they add more MT Security we feel it as well, the reason we are on-prem is because of the openess, we want to use Sys Tables and other tables. I think @Bart_Elia is also a big fan of moving MT away.
That is known issue. I’m sorry. We fixed it in 10.2.400 but I didn’t receive any official hotfix requests for 10.2.300.
Awesome! Yeah I just noticed it not to long ago, figured @josecgomez would ask Rich about it at Insights and bring back info 
But that is GREAT News!!! Thanks Dimitri! Nice!!
Would it help if I put in a ticket, could it be possibly fixed then in a Patch 10.2.300.x level ?
In February, I submitted a case (CS0001355098/TASK6901539) because of my SOX reporting. I needed to see who was a temporary support person with Security Manager. In the Erp table, the users look like they are active Security Managers but in the Ice.UserFile, I can see when the temporary access ends. I really didn’t need access to the the Ice.UserFile fields but only the UD portion of those fields which is where the temp access is stored. Unfortunately there is no link available (like user ID or systemID from Erp.UserFile) and it broke all of our SOX reports. 
Long time ago!
This actually appeared in 10.2.200. 
I wonder if they will fix it for Cloud Customers or only On-Prem.
I don’t think they will for Multi-Tenant because that’s a legitimate privacy/security issue but it sure would be nice for Dedicated Tenant/Public Cloud users where the whole database belongs to one organization.
