When using the Session Relevance Tester, or the /webreports?page=QNA page, you donāt URL-encode the query. The URL-encoding is usually handled by the scripting language or programming tool (even CURL with the --data-urlencode option), you only need to do the URL-encoding when you are using the browser address bar to send a query.
Your un-encoded query to start with is then
((values of it, name of computer of it) of results of it, names of it ) of properties of bes analysis whose (name of it is "AnalysisName")
You can get the āSingular Expression refers to nonexistent objectā because you refer to the singular āname of computer of itā. In some cases this query might retrieve a computer that has not reported itās computer name and would throw the error. You can avoid that by using the plural 'names of computers of it (which discards the whole result row for a missing computer name), or use the pipe operator ā|ā to replace the value where an error is thrown, ie
((values of it, name of computer of it | "Name not reported") of results of it, names of it ) of properties of bes analysis whose (name of it is "AnalysisName")
You may also filter to only the computers you want by using a whose() clause on the 'bes property results objects
((values of it, name of computer of it | "Name not reported") of results whose (name of computer of it = "My computer name") of it, names of it ) of properties of bes analysis whose (name of it is "AnalysisName")
That should get the results you want, but it can still be made more efficient. For each of these properties, this query loops through every result before filtering down to the computer in which you are interested. For a lot of properties with a lot of results, that can get pretty slow. Think of it as a SQL query, where you can get great efficiency gains by filtering as early as possible before performing a JOIN. The blog post on āefficient property retrievalā posted earlier is a great resource.
By building a set of the BES Properties and a set of the BES Computers we want, first, we can look specifically for the results between that computer for that property, instead of looping through the results for every computer. We could look for a single computer instead of building a set of BES Computers in this case (since there should only be one element to the set), but I like this pattern because it allows flexibility in changing from one computer, to a computer group, or computername patterns, and is easier to modify.
(value of it, name of computer of it | "ComputerName not reported", name of property of it) of (results (elements of item 0 of it, elements of item 1 of it)) of (set of bes computers whose (name of it = "MyComputerName"), set of properties of bes analysis whose (name of it is "BES Component Versions"))