Un principiante en las Artes Gráficas

Una de las características fundamentales de los sistemas ERP es el ofrecer información útil para el usuario. Generalmente, esa información útil surge de cruzar datos de diferentes orígenes (en nuestro caso, tablas de base de datos).

Vamos a poner un ejemplo: En AbanQ tenemos el formulario de artículos dentro del módulo de almacén. Quizás sería interesante añadir una opción para comprobar los movimientos de stocks, entendiendo por los mismos las entradas a almacén (albaranes dados de alta) y salidas (albaranes a clientes). Sería interesante visualizar en un TableDB el resultado de una query que agrupara ambas entradas. Claro, ocurre que para hacer esa query, es necesario utilizar una cláusula SQL, union.  Así por ejemplo, podríamos desear tener una consulta tal como esta

select 'Entrada' as tipo, lp.referencia, lp.cantidad, ap.idalbaran
from albaranesprov as ap inner join lineasalbaranesprov as lp
on ap.idalbaran = lp.idalbaran
union
select 'Salida' as tipo, lc.referencia, lc.cantidad, ac.idalbaran
from albaranescli as ac inner join lineasalbaranescli as lc
on ac.idalbaran = lc.idalbaran

Si usáis PosgreSQL, lo ideal, es crear esta consulta como una vista (así garantizáis que la consulta se encuentra precompilada y optimizada antes de ejecutarse, lo que proporciona una mayor velocidad de ejecución, en general). Pongamos por ejemplo, que esta consulta le damos el nombre tvw_movimientosstock.

Ahora bien, ¿cómo maneja AbanQ las vistas en PostgreSQL? No las maneja, ni falta que hace (bueno, relativamente). Como utiliza las Qt, éstas hacen transparente el acceso a tablas y/o vistas en PostgreSQL por el driver que traen integrado. Esto significa que podemos crear una vista, y acceder a ella desde AbanQ generando el archivo de metadatos de tabla .mtd y el archivo de query .qry correspondiente. Sólo hay que tener en cuenta un par de detalles.

Veamos el archivo Query movimientosstocksqry.qry.

<!DOCTYPE QRY>
<QRY>
	<name>movimientosstocksqry</name>

	<tables>lineasalbaranesprov,albaranesprov</tables>

	<select>
		tipo, referencia, cantidad, idalbaran
	</select>

	<from>
		tvw_movimientosstocks
	</from>

	<where>
	</where>

	<order>
	</order>
</QRY>

El contenido de <table> “importa poco”, ya que quien realmente tiene la información de cómo acceder es el elemento vista tvw_movimientosstock. El .mtd es sencillo: movimientosstocksqry.mtd

<!DOCTYPE TMD>
<TMD>
    <!--dpinelo: Tabla creada para mantener el almacen de papeles-->
    <name>movimientosstocksqry</name>
    <query>movimientosstocksqry</query>
    <alias>QT_TRANSLATE_NOOP(&quot;MetaData&quot;,&quot;Movimientos del stocks&quot;)</alias>
    <field>
        <name>referencia</name>
        <alias>QT_TRANSLATE_NOOP(&quot;MetaData&quot;,&quot;Referencia&quot;)</alias>
        <null>false</null>
        <type>string</type>
        <length>18</length>
    </field>
    <field>
        <name>tipo</name>
        <alias>QT_TRANSLATE_NOOP(&quot;MetaData&quot;,&quot;Movimiento&quot;)</alias>
        <null>true</null>
        <pk>false</pk>
        <type>string</type>
        <length>20</length>
    </field>
    <field>
        <name>cantidad</name>
        <alias>QT_TRANSLATE_NOOP(&quot;MetaData&quot;,&quot;Cantidad&quot;)</alias>
        <null>true</null>
        <pk>false</pk>
        <type>uint</type>
    </field>
    <field>
        <name>idalbaran</name>
        <alias>QT_TRANSLATE_NOOP(&quot;MetaData&quot;,&quot;ID Albarán&quot;)</alias>
        <null>true</null>
        <pk>false</pk>
        <type>uint</type>
    </field>
</TMD>

En este .mtd lo que hay que tener claro y en cuenta, es que el nombre de la tabla (<name>) y el de la query (<query>) deberían coincidir. ¿Porqué? Para que no se cree una tabla con el nombre de la vista. De esta forma, podemos asignar en cualquier FLTableDB el nombre de la tabla que queremos mostrar a esta query (incluso con foreign key), garantizando la ejecución desde una vista, y cierta mejora en el rendimiento.

Por contra, AbanQ no está preparado para trabajar con vistas explícitamente: No las espera. Por tanto no esperéis que las administre. Eso es labor vuestra, directamente en PostgreSQL (atentos por ejemplo, al tema permisos).