Also, you can use the built-in %RD routine.  After you enter the routine name or names that you want to see the sizes for, then answer "L" for Long Form at the next prompt.   that will display additional attributes about the specified routines - one of which will be the size in bytes.

Example Output:

                 Long Listing of Selected Routine/Include Files
                              Namespace:  TEST
                         22 Aug 2016  6:14 PM   Page 1

NAME                            .EXT.VER  LANG  DATE/TIME             #BYTES

UTTest                          .MAC            20 May 2016  10:21 am  14252
 

If you just want to see data for the class query, then you can also run the query interactively via your Cache Terminal window (or any other type of terminal emulator, such as Putty, Reflections, PowerTerm, etc...).

Here is the command to run the class query from your example:

Do ##class(%ResultSet).RunQuery("LastName.BasicClassQuery","Display")

Note:  If your query accepts input parameters, then you just include them as the 3rd-nth parameters - an example of what that might look like if you needed to pass two input values to your query:    Do ##class(%ResultSet).RunQuery("LastName.BasicClassQuery","Display","value1","value2")

This will list the data in your terminal window and might look something like this:  Notice the first row that is displayed is all your column names (i.e. property names) and all the subsequent rows that are displayed is the data from your table(s).

Code:Name:IsActive:ID:
AF:Archived Forms:1:31:
AR:AdHoc Feedback Report:1:29:
AT:Stain/Request Audit Report:1:11:
CH:Cyto-Histo Correlation:1:23:
CPS:Cytology Population Statistics:1:22:
 

Hi Benjamin,

As a fellow Cache Developer I can offer a couple of suggestions.  If you want the user to have to wait for the server side processing to complete before continuing with their work, then you could override the CSP Gateway Response Timeout:

1.  If you are working with a ZEN page (i.e. that extends from %ZEN.component.page), then you could implement an overridden version of the OnPreHyperEvent method

Example:

 /// OnPreHyperEvent - Event handler which is invoked before a hyperevent
///   method is called on all Zen pages. The purpose of this method is to
///   allow various configuration settings to be overridden prior to making
///   the actual hyperevent call (i.e. executing a query for a tablepane).
ClassMethod OnPreHyperEvent(class As %String, method As %String) As %Status [ ServerOnly = 1 ]
{
// Override the CSP Gateway Response Timeout
Set %response.Timeout={numberOfSecondsYouWantToAllowForServerProcessingToCompleteBeforeRequestTimesOut}

// Call built-in Zen Controller pre hyperevent method
Quit ##class(%ZEN.Controller).OnPreHyperEvent(..%ClassName(1),$G(method),+..#AUTONS,..#RESOURCE)
}
 

2.  If you are working with a CSP page (i.e. that extends from %CSP.Page), then you could implement an overridden version of the OnPreHTTP method

Example:

 /// Event handler for <b>PreHTTP</b> event: this is invoked before
/// the HTTP headers for a CSP page have been sent. All changes to the
/// <class>%CSP.Response</class> class, such as adding cookies, HTTP headers,
/// setting the content type etc. must be made from within the OnPreHTTP() method.
/// Also changes to the state of the CSP application such as changing
/// %session.EndSession or %session.AppTimeout must be made within the OnPreHTTP() method.
/// It is prefered that changes to %session.Preserve are also made in the OnPreHTTP() method
/// as this is more efficient, although it is supported in any section of the page.
/// Return <b>0</b> to prevent <method>OnPage</method> from being called.
ClassMethod OnPreHTTP() As %Boolean [ ServerOnly = 1 ]
{
// Override the CSP Gateway Response Timeout
Set %response.Timeout={numberOfSecondsYouWantToAllowForServerProcessingToCompleteBeforeRequestTimesOut}
Quit $$$OK
}
 

But another option to consider is to implement the ZEN page, so the user can provide the input criteria (if any) for retrieving table data and instead of having the user click a [Search] button to run the server side lookup in foreground mode (i.e. where user has to wait for the server processing to complete), you could instead implement a [Run In Background] button where you job off the server side processing, so it can run in the background, which allows the user to do other things with the application and they can check back at a later point for the status.   You could have some type of mechanism on the ZEN page that shows the user the status of the background process (i.e. Running, Completed, Error, etc...);   You can refer to the built-in  %RunBackgroundMethod method or you could implement your own application specific background type processing - example:  As the user submits various background jobs to run, you could have a tablepane display the various processes that are running with their status - then when complete, you could have a link in that table the user could click to display the associated data that was retrieved from the server.

Hope this helps and Have a Great Day!!    Happy Coding!