Campos de tipo objeto

El contenedor

Los datos de los campos de tipo objeto (texto, texto enriquecido, dibujo, etc.) no se almacenan en el registro, se guardan en el contenedor, en el registro se guarda el índice de la primera celda del contenedor que tiene el contenido del objeto.

Por lo tanto cuando se cargan los datos del registro todavía no tenemos la información de los objetos que queremos visualizar. Esto obliga a realizar una petición de información al servidor para obtener el contenido de los campos objeto, que además por su tamaño suele requerir más de un socket, aunque se utilizan los sockets envolventes para optimizarlo.

Carga en 2º plano

La carga de objetos se realiza en segundo plano, no paralizando la interfaz al usuario que podrá seguir trabajando con la aplicación mientras se siguen cargando los campos objeto. Es el mismo sistema que se aplica a los campos puntero a maestro.

Una vez que el objeto ha sido cargado se guarda en caché lo que ayuda a obtener un buen rendimiento tras la primera carga.

¿Cómo optimizar?

Si, por ejemplo, queremos sacar un objeto en una columna de una rejilla tendremos que asumir que esos datos se cargarán en segundo plano y llegarán con retraso respecto a los datos del registro. En Cloud este efecto se nota, en local es mucho menos notable.

Siempre que sea posible deberíamos optimizar nuestra rejilla no mostrando la columna del objeto por defecto, y que sea el usuario el que produzca el cambio de visor por una rejilla que sí contenga esa columna. La ventaja es que con todos los datos en caché el efecto de la carga de los objetos produce una mejor sensación para el usuario. Todos asumimos cuando navegamos por Internet que las imágenes tardan más en cargar.

Otro método que se usa en ocasiones es utilizar la configuración del usuario para determinar si es un usuario con conexión local o remota y determinar en función de ese valor si se le muestra el visor de datos optimizado (sin campos objeto, por defecto) o completo (sin optimizar).