AS/400 - Lógicos con filtros de seleccion/omision

Buenos días.

Observo cuando creo un logico en el que aparte de campos claves añado un filtro de selección, por ejemplo,

Tabla1 (DNI, NOMBRE, CIUDAD) con muchos millones de registros

Creo el logico por DNI y CIUDAD e indico como filtro en la DDS que CIUDAD sea 'HUELVA'.

Si abro el logico por DFU se me posiciona inmediatamente en el primer registro que tiene como CIUDAD='HUELVA' y DNI más bajo. Es decir el logico va perfecto,

Sin embargo si ejecuto un SQL o QRY observo como este va recorriendo toda la tabla (seleccionados X de Y) y como tarda un montón.

¿Porque es esto así? Entiendo que un programa RPG que cree tambien accederá instantaneamente pero porque los SQL y QRY no? ¿Hay que definir algo al ejecutar estos?

Un saludo!

Cuando accedes por un archivo lógico, ya tiene armado (construido) el índice (mejor dicho su "via de acceso"), mientras que en un SQL o query está realizando (en cada ejecución) la construcción de dicha vía de acceso, es como si en cada ejecución a través del sQL o del query crearas el archivo lógico.
Tanto el SQL como el query (sobre todo sobre archivos enormes y aplicando varios criterios de selección y ordenamiento) se recomienda utilizarlo en ambiente batch donde se ejecutan con una prioridad de ejecución menor.
Espero te ayude estos comentarios

Jesús Acuña
www.cursos-as400.com

No me cuadramucho tu respuesta. en muchas ocasiones he creado logicos (índices) para sql que iban muy lentos y estos han mejorado sustancialmente. el caso se me da solo en logicos con filtros.

muchas gracias por tu respuesta.

Tocayo, tienes toda la razón, mi explicación no está completa y tu comentario me permite ver una ausencia en mi explicación.
En lo que es SQL (SELECT ..... ORDER BY ... ) no por colocarle ORDER BY se crea o se ha creado un indice, el SELECT buscará el mejor "plan de navegación", es decir el mejor índice (una vez más anoto que deberíamos emplear el termino "via de acceso" en vez de índice , dado que el AS/400 no usa punteros para el ordenamiento de registros sino la técnica del "árbol binario"), entonces si encuentra un lógico que cumpla lo especificado en el ORDER BY lo usará y será rápido su ejecución, por el contrario sino existe ningún lógico que cumpla lo del ORDER BY entonces creará una "via de acceso" en tiempo de ejecución, ello explica tu comentario: " he creado logicos (índices) para sql que iban muy lentos y estos han mejorado sustancialmente".
En el caso de aplicar criterios de selección en el SQL no sucede lo mismo (hasta donde yo se) es por ello que el SQL con criterios de selección procesa en tiempo de ejecución todos los registros del archivo aplicando el criterio de selección.
Espero ahora haber complementado un poco mi comentario anterior y haber sido de ayuda .

Jesús Acuña
www.cursos-as400.com

Veras en el as400 hay varios tipos de lógicos por comportamiento y construcción:

Lógicos que guardan los punteros del fichero principal
Lógicos “físicos” que guardan los datos

Lógicos de tipo “vista” que no guardan los punteros, pues son dinámicos (se crean en tiempo de demanda)
Lógicos de tipo “vista-físicos” que no guardan los punteros pues son dinámicos (se crean en tiempo de demanda)

Lógicos de unión de estructuras iguales que te permiten mantener en un lógico todos los ficheros de igual estructura pero de bibliotecas diferentes.

A muchos de esto lógicos no se tiene acceso nada más que por programación, el SQL o el QRY les sientan mal pues son contrarios a su forma de leer ficheros.

Buenas!

A ver si me puedes aclarar esto:

Suponiendo el fichero fisico (numerofactura, dni, campo1 .... campo n) , suponiendo un logico por dni

[1] Lógicos que guardan los punteros del fichero principal: crearia un fichero (dni, nº reg) ordenado por dni donde nº reg indicaria el numero de registro (fila) del fisico al que hace referencia ¿?

[2] Lógicos “físicos” que guardan los datos: crearia un fichero (dni, numerofactura, campo1 .... campo n) ordenado por dni ¿?

[3] Lógicos de tipo “vista: como [1] pero se contruyen dinamicamente , los tipicos trabajos IDX-xxxxx que aparecen cuando se ejecuta un SQL o QRY ¿?

[4] Lógicos de tipo “vista-físicos” : como [2] pero se contruyen dinamicamente , los tipicos trabajos IDX-xxxxx que aparecen cuando se ejecuta un SQL o QRY ¿?

En cualquier caso tal y como planteas entiendo que el SQL/QRY cuando existe un logico creado por DDS con filtros , pese a llamarlo directamente (select * from logico) no se lleva muy bien e ignora el filtro de selección. ¿es eso, no?

Como he planteado tengo clarisimo que ni no es por selección funciona correctamente, cree en una tabla parecida a la expuesta con muchos millones de registros un logico por dni el cual se llevo como 45 minutos, un avez contruido al preguntar en SQL algo por DNI en lugar de 15 minutos no tardaba mas de 3 segundos, con lo cual descarto que lo contruya dinamicamente.

Muchas gracias!

************************************************
R RXXONA PFILE(FXXXX)

K FXXTRA
K FXXAÑO
K FXXPED
K FXXLIN

S FX1 COMP(EQ '* ')
S FX2 COMP(EQ ' * ')
S FX3 COMP(EQ ' *')
**** Fin de datos *****************************
Lógico normal de punteros, tiene acceso a todos los datos del principal.

*******************************************************
R RCLIE1 PFILE(LIB1/CLIENTES)

CODIGO

K CODIGO
S CPOSTAL COMP(EQ '08824')

R RCLIE2 PFILE(LIB2/CLIENTES)

CODIGO

K CODIGO
S CPOSTAL COMP(EQ '08824')
*******************************************************
Lógico de punteros que une el mismo fichero en bibliotecas diferentes y con acceso a todos los datos, si te fijas tiene 2 registros en el mismo lógico.(ojo este no es capaz de leerlo el SQL o QRY)

Aquí te he colocado un par de lógicos “normales” con selección, pero podía haber sido sin ella.

*******************************************************
*******************************************************
*******************************************************
DYNSLT <= esto le dice al lógico que es dinámico, vamos que se genera bajo llamada
R R3 JFILE(AC1 ACD1)
J JOIN(1 2)
JFLD(AÑO1 AÑO2)
AÑO1
DIA2
MES1

K AÑO1
S DIA2 COMP(EQ 25)

Este lógico es dinámico y con datos propios ( AÑO1, DIA2,MES1) por lo que solo tiene acceso a esos datos.
*******************************************************
R R3 JFILE(AC1 ACD1)
J JOIN(1 2)
JFLD(AÑO1 AÑO2)
AÑO1
DIA2
MES1

K AÑO1
S DIA2 COMP(EQ 25)

Este lógico es “físico” y con datos propios (AÑO1, DIA2, MES1) por lo que solo tiene acceso a esos datos pero además guarda los datos físicamente.

En cuanto a las combinaciones pueden ser diversas.
El SQL tiende a utilizar muchas veces el lógico que mas le conviene a la consulta que hagas y sobre ese lógico monta la consulta, para ver de verdad el lógico que esta utilizando tiene que mirar las alteraciones temporales de fichero.

Ya se que la explicación es algo espartana, pero es bastante grande el tratado de lógicos.

Espero haberte aclarado algo el tema, un saludo.

Buenas Tardes,

Actualmente me encuentro desarrollando unos programas SQLCBL, es decir Coboles con SQL embebedio para el AS400. Mi pregunta es, si estoy manejando SQL Dinamico es decir armo la sentencia en un String para luego ser ejecutado. Si creo Archivos Logicos con un indice que le sirva a la consulta, el SGBD cuando arma la peticion SQL toma/utiliza el Archivo Logico???

Gracias de antemano por la atención prestada,