So it creates a new table (should be the one you are seeing...I don't see your screen shot). That's actually the table you will run reports off of...but it should be empty at the moment.
So the way the table gets populated, is you go into a variable for an item and you should see a new true/false check box "Visible on variable log". You will have to switch this property to true for every variable you want to be able to pull a report on... If you have a lot and want to run it on all, I'm sure a script could take care of that. Our instance is relatively new, so I just did it in mass. What should occur now is that everytime an item is ordered...any variable with that box checked will create a new record in the new table with the request item number and any variable you want logged attached to it. So it only applied to requests created from now forward...
We wanted to pull reports on everything we've ever done, so I took the script that came packaged with the update set, and put it into a scheduled job and ran it. This populated the table with pretty much every variable ever filled in by anyone on our instance, and the attached request item. So we can pull full reports on the variables now.
Darshan,
Are you sure? I am in Calgary and I can produce a report on the Variable Ownership table and filter by the Question (in Anthony's case he would be searching for a Requested For variable) to retrieve a list of RITM records.
As I understand, filtering by Variables directly on the RITM table (the first Heading in the Wiki Article) is a Eureka feature (and a fantastic one at that).
But querying on the Variable Ownership table is the legacy method that is backwards compatible with previous versions.
Example from Calgary:
