SetLoadFields

SetLoadFields o registros parciales

¿Qué son y para qué se usan?

Como sabemos, los datos que utiliza Business central están alojados en una base de datos SQL.
Por ejemplo, vemos las tablas de las que dispone y nos fijamos en la tabla de productos, la tabla Item

Aunque en la imagen  vemos que se resaltan 2 tablas, la primera es la tabla estándar, la tabla nº 27 Item y la segunda es, o son, todas las extensiones sobre esa tabla que pueda haber.
Cada vez que mediante una extensión de tabla se añade un nuevo campo, se refleja en la segunda tabla que vemos en la imagen utilizando el campo clave como nexo de unión entre la tabla estándar y la tabla extensión.
En este caso los campos que tiene la tabla de  extensión los añade la extensión de Intrastat.
Vamos a añadir los nuestros propios para ver el resultado:

tableextension 50001 "ItemExt" extends Item

{

    fields

    {

        field(50001; "TPV Item"; Boolean)

        {

            Caption = 'Producto TPV';

            DataClassification = ToBeClassified;

        }              

    }    

}

Añadimos un nuevo campo de tipo boolean en que indicamos si el producto es un producto utilizado para un TPV o no.
Publicamos y observamos el resultado en SQL

Vemos como nuestro nuevo campo aparece a continuación de los ya existentes en la misma tabla.

Todo esto es una introducción a lo que ocurre internamente cuando trabajamos con registros.
Hasta la introducción de SetLoadFields mientras trabajábamos en AL con tablas, se cargaban todos los campos que contenían las tablas que componían lo que Business central entendía como productos, en este caso; según la imagen, la unión de las 2 tablas señaladas.
Pero cabe añadir que la unificación de los campos de todas las extensiones en una sola tabla es algo reciente, se incluyó a partir de la versión 23, anteriormente tendríamos:

• Tabla Item estandar.
• Tabla Item extensión 1
• Tabla Item extensión 2
• ...
• Tabla Item extensión n

Lo que producía internamente una consulta más compleja y por lo tanto menos ágil. Si lanzamos un Findset de la tabla Item, internamente se ejecutaría un Select en SQL con la unión de todas las tablas de todas las extensiones de esa tabla.
Al reducir las tablas de extensiones, las consultas de datos se simplifican, lo podemos ver de una manera gráfica en una consulta sobre la tabla Item

Lo que vemos en la imagen equivaldría a esto en nuestro código :

    procedure GetAllItems()

    var

        Item: Record Item;

    begin

        if Item.FindSet() then;

    end;

Vale, y todo esto ¿qué significa?

Si volvemos a fijarnos en la imagen de la consulta en SQL, se cargan todos los campos de las 2 tablas, se utilicen o no.

Esto deriva en que a mayor cantidad de datos, más tiempo para disponer de esos datos.

Imaginemos que en nuestro código necesitásemos sólo el campo descripción.
La consulta óptima para esto sería:

¿Y cómo hacemos esto en nuestro código?

Utilizando SetLoadFields:

    procedure GetAllItems()

    var

        Item: Record Item;

        TxtBuilder: TextBuilder;

    begin

        Item.SetLoadFields(Description);

        if Item.FindSet() then

        repeat

            TxtBuilder.Append(Item.Description);

        until Item.Next() = 0;

    end;

Si nos fijamos, en la línea Item.SetLoadFields(Description); se indica que sólo utilizaremos el campo descripción con lo que los demás campos no serán usados y por lo tanto optimizaremos el rendimiento de la consulta.
Quizás en una tabla con 100 o 1000 registros no se note mucho la diferencia, pero si necesitamos mover una tabla con millones de registros notaremos la diferencia, y mucho.

Existen extensiones de Visual  Studio Code que añaden automáticamente la línea con los campos a utilizar en función del uso que hagamos de ellos y nos facilitan su uso.

Como añadido quisiera comentar que debemos tener cuidado con añadir campos al código una vez definido el SetLoadFields, ya que si definimos unos campos en SetLoadFields, pero luego usamos otros distintos obtendremos una advertencia denominada JIT (Just-in-time), en nuestro ejemplo podemos forzarlo:

    procedure GetAllItems()

    var

        Item: Record Item;

        TxtBuilder: TextBuilder;

        PriceSum: Decimal;

    begin

        Item.SetLoadFields(Description);

        if Item.FindSet() then

            repeat

                TxtBuilder.Append(Item.Description);

                PriceSum += Item."Unit Price";

            until Item.Next() = 0;

    end;

Estamos utilizando el campo Unit Price, pero no lo hemos indicado en SetLoadFields.
Tanto el entorno nos avisará de esto, como Business central en cuanto ejecutemos el código

Al no disponer del campo en el Select original, el sistema se ve forzado a realizar otro Select tal y como indica Microsoft en su documentación:

A pesar de que se hará una lectura del registro en concreto debemos evitar estas situaciones.

Por esto, debemos estar atentos a las advertencias, ahora ya sabemos lo que significa o lo que es un aviso JIT y a qué se debe.

Nos vemos en el siguiente post.

Espero que os sea de utilidad.