La importancia de ‘set Row = “”’ en el método Fetch de las consultas de clase

Una de nuestras apps utiliza una consulta de clase para un informe ZEN y funciona perfectamente en ese informe, produciendo los resultados esperados. Hemos migrado a InterSystems Reports y nos hemos dado cuenta de que, para un informe que utiliza la misma consulta de clase, aparecen en la parte de abajo más de 100 filas extra con los mismos valores en las columnas.

Descartamos InterSystems Reports como fuente del problema reproduciendo el problema de "filas extra" con una hoja de cálculo de Excel que llama a la misma consulta de clase utilizando un procedimiento almacenado.

¿Cuál era el problema? Cuando llamábamos al procedimiento almacenado desde el antiguo ZEN Report o desde la función SQL Query en el Portal de Administración, no veíamos estas filas adicionales.

Comparamos nuestro código de consulta de clase con la información ofrecida en el artículo de @Eduard Lebedyuk y encontramos el problema. Consultas de clase en InterSystems IRIS

Aunque se estableció correctamente el argumento ByRef “AtEnd” cuando ya no quedaban resultados, el método “Fetch” no establecía "Row" como cadena vacía.

Parece que estableciendo “AtEnd” funciona para terminar los resultados de la consulta en ciertos casos (MP SQL), pero 'set Row = ""' es necesario para todos los casos, como para las solicitudes desde JDBC (InterSystems Reports) u ODBC (Excel).

Este es nuestro método Fetch actualizado:

ClassMethod QueryNameFetch(ByRef qHandle As %Binary, ByRef Row As %List, ByRef AtEnd As %Integer = ) As %Status [ Internal, PlaceAfter = QueryNameExecute ]
{
    If 'qHandle.ResultSet.Next() {
        Set AtEnd = 1
        set Row = "" // <=========== Previously missing line
        Quit $$$OK
    } // Stuff all the result columns into one big $LIST in Row
    set Row = ""
    set ncols = qHandle.ResultSet.%ResultColumnCount
    for i=1:1:ncols {
        set Row = Row _ $lb(qHandle.ResultSet.GetData(i))
    }
    Quit $$$OK }</pre></body></html>