SQL, join e record non trovato

[MarcoP]

Buongiorno a tutti,

ho un problema con un programma in SQLRPGLE, che dato un numero di
lavorazione deve reperire i dettagli degli ordini cliente collegati.

Ogni riga che recupero, quindi è composta dal numero di lavorazione,
più:
- anno, numero, riga ordine
- data di consegna prevista
- cliente (con decodifica)
- articolo (con decodifica)
- quantità ordinata/residua
- altri dettagli della riga ordine

Finora con le normali decodifiche ho usato il COALESCE (avevo provato
anche IFNULL), ma adesso la cosa si complica: su 25 campi totali del
mio SFL, dovrei usarlo su 22, restano esclusi anno-numero-progr.
lavorazione che sono il dato principale.

C'è qualche opzione che mi permette di rendere "implicito" il
COALESCE nella mia SELECT?

Poi perché se faccio STRSQL e incollo l'istruzione SELECT che faccio
nel mio programma per visualizzare i dati in un SFL, a video vedo
tutto e nel programma si blocca?

Devo definire i campi interni dell'RPGLE (o quelli del SFL), in
qualche modo particolare?

Grazie in anticipo.

[Mauro Romeo]

Post by MarcoP
Buongiorno a tutti,
ho un problema con un programma in SQLRPGLE, che dato un numero di
lavorazione deve reperire i dettagli degli ordini cliente collegati.
Ogni riga che recupero, quindi � composta dal numero di lavorazione,
- anno, numero, riga ordine
- data di consegna prevista
- cliente (con decodifica)
- articolo (con decodifica)
- quantit� ordinata/residua
- altri dettagli della riga ordine
Finora con le normali decodifiche ho usato il COALESCE (avevo provato
anche IFNULL), ma adesso la cosa si complica: su 25 campi totali del
mio SFL, dovrei usarlo su 22, restano esclusi anno-numero-progr.
lavorazione che sono il dato principale.
C'� qualche opzione che mi permette di rendere "implicito" il
COALESCE nella mia SELECT?
Poi perch� se faccio STRSQL e incollo l'istruzione SELECT che faccio
nel mio programma per visualizzare i dati in un SFL, a video vedo
tutto e nel programma si blocca?
Devo definire i campi interni dell'RPGLE (o quelli del SFL), in
qualche modo particolare?
Grazie in anticipo.

Devi definire per ogni campo che può contenere un null un campo integer
di 3,0 e nella fetch dirai fetch cursore into :campo:integer.
A quel punto devi testare il campo integer per sapere se nel campo dati
c'e' un valore valido o un null (se null integer dovrebbe contenere -1),
comunque a livello di lettura non avrai più errori
Mauro Romeo

[Stefano Tassi]

Post by MarcoP
Buongiorno a tutti,
ho un problema con un programma in SQLRPGLE, che dato un numero di
lavorazione deve reperire i dettagli degli ordini cliente collegati.
Ogni riga che recupero, quindi è composta dal numero di lavorazione,
- anno, numero, riga ordine
- data di consegna prevista
- cliente (con decodifica)
- articolo (con decodifica)
- quantità ordinata/residua
- altri dettagli della riga ordine
Finora con le normali decodifiche ho usato il COALESCE (avevo provato
anche IFNULL), ma adesso la cosa si complica: su 25 campi totali del
mio SFL, dovrei usarlo su 22, restano esclusi anno-numero-progr.
lavorazione che sono il dato principale.
C'è qualche opzione che mi permette di rendere "implicito" il
COALESCE nella mia SELECT?
Poi perché se faccio STRSQL e incollo l'istruzione SELECT che faccio
nel mio programma per visualizzare i dati in un SFL, a video vedo
tutto e nel programma si blocca?
Devo definire i campi interni dell'RPGLE (o quelli del SFL), in
qualche modo particolare?
Grazie in anticipo.

puoi disegnare una vista, anche molto complessa, che include i coalesce
e selezionare quella all'interno del tuo rpg

[MarcoP]

Post by Stefano Tassi
puoi disegnare una vista, anche molto complessa, che include i

coalesce

Post by Stefano Tassi
e selezionare quella all'interno del tuo rpg

Ok, la strada della VIEW è quella che mi piace di più, e mi sembra
anche più gestibile poi in SQLRPGLE

L'unica cosa è che risulta poi pesante per l'AS... Sfido io: per ogni
progressivo di lavorazione calcola il saldo, richiama le
caratteristiche principali (articolo e dettagli), elenca gli ordini
abbinati e fa un paio di decodifiche...

Forse sbaglio approccio, o forse posso ottimizzare le prestazioni?

Devo dire che non ho mai usato le view, e neanche le index (forse una
volta), ma non ho ben capito se posso creare una view "preordinata", o
qualcosa del genere...

Una dritta?


P.S. magari togliendo quel paio di decodifiche ottengo già qualcosa! Mi
sa che sono un "di più" che non serve.

[Stefano Tassi]

Post by Stefano Tassi

Post by Stefano Tassi
puoi disegnare una vista, anche molto complessa, che include i

coalesce

Post by Stefano Tassi
e selezionare quella all'interno del tuo rpg

Ok, la strada della VIEW è quella che mi piace di più, e mi sembra
anche più gestibile poi in SQLRPGLE
L'unica cosa è che risulta poi pesante per l'AS... Sfido io: per ogni
progressivo di lavorazione calcola il saldo, richiama le
caratteristiche principali (articolo e dettagli), elenca gli ordini
abbinati e fa un paio di decodifiche...
Forse sbaglio approccio, o forse posso ottimizzare le prestazioni?
Devo dire che non ho mai usato le view, e neanche le index (forse una
volta), ma non ho ben capito se posso creare una view "preordinata", o
qualcosa del genere...

il db2 non prevede l'order by nelle view
puoi però ovviamente gestirlo nel sqlrpgle

select col, col col
from view
order by col, col

gli indici aiutano/risolvono problemi di performances.
considera che la view altro non è che una semplificazione della tua
query, in pratica ti evita di dover essere verboso nel programma ma non
fa nulla di più.
Se avevi necessità di indici prima (senza view) gli stessi indici ti
servono se usi una view.
tipicamente (ma un giretto di index advisor non fa male)
gli indici dovranno esistere per i campi di join e di where nelle
tabelle joinate, nelle where delle subselect, negli order by, ma ogni
query è una storia a sè stante; il suo utilizzo da parte del dbmanager
dipende da tanti fattori, non ultimo dalla numerosità della tabella.

Post by Stefano Tassi
Una dritta?
P.S. magari togliendo quel paio di decodifiche ottengo già qualcosa! Mi
sa che sono un "di più" che non serve.

non togliere le decodifiche, tanto dovrai farle dopo con delle chaim,
non so quanto tu ci possa guadagnare.

[MarcoP]

Stefano Tassi <***@nomail.com> ha scritto:

Mi dilungo nel rispondere, perché l'analisi e le prove che sto facendo mi
risultano FONDAMENTALI per questo e per prossimi lavori...
Non saprei come spiegare quale valore aggiunto posso ricavare ottimizzando
le prestazioni di queste letture (un po' lo si capisce da quanto scrivo di
seguito).

Post by Stefano Tassi
il db2 non prevede l'order by nelle view
puoi però ovviamente gestirlo nel sqlrpgle

Che è quello che faccio, con una order by predefinita per:
- anno e numero lavorazione
- anno/numero ordine/i a cui si riferiscono le lavorazioni

Post by Stefano Tassi
gli indici aiutano/risolvono problemi di performances.
considera che la view altro non è che una semplificazione della tua
query, in pratica ti evita di dover essere verboso nel programma ma non
fa nulla di più.
Se avevi necessità di indici prima (senza view) gli stessi indici ti
servono se usi una view.
tipicamente (ma un giretto di index advisor non fa male)
gli indici dovranno esistere per i campi di join e di where nelle
tabelle joinate, nelle where delle subselect, negli order by, ma ogni
query è una storia a sè stante; il suo utilizzo da parte del dbmanager
dipende da tanti fattori, non ultimo dalla numerosità della tabella.

E' qui che sono indeciso su come agire, anche perché non ho tutte le
conoscenze necessarie, e in pratica sto sperimentando adesso per dare più
performance al programma.
Mi spiego: nella view avevo fatto le classiche join di una select standard,
facendo riferimento a fles logici con indici e omissioni dei record
annullati, ma la create view non me lo permette perché vuole files fisici.
Quindi ho usato i fisici, e ho messo nella LEFT JOIN la condizione per
scartare gli annullati (non nella WHERE perché non devono essere scartati
record annullati del magazzino, che è il file principale, in conseguenza di
annullamenti sui files delle join).

Poi visto che la lettura dei dati risultava pesante, ho lanciato il mio
programma sotto debug per analizzare i messaggi dell'SQL, che, in pratica,
mi dice di creare degli indici/files logici come quelli che ho già, ma in
chiave vuole il flag di annullamento.

Sicuramente farò ulteriori prove per creare i logici che chiede, e
confrontare le prestazioni, ma metto in conto che ci possa essere una
strada più conveniente.

Tempo fa (un paio di anni) qui si era parlato di parametri a livello di
sistema che davano prestazioni più performanti all'SQL rispetto al DB2 con
mille considerazioni possibili in base anche alla versione del sistema
operativo.
All'epoca ero limitato nelle decisioni, e lavoravo con un AS a V5R4, oggi
sono totalmente autonomo ed ho una V7R1. Cambia tutto sia per le scelte che
posso fare che per la versione dell'OS!

Post by Stefano Tassi
non togliere le decodifiche, tanto dovrai farle dopo con delle chaim,
non so quanto tu ci possa guadagnare.

Buono a sapersi, sia per l'uso di SQL che per le possibilità del programma!
L'ordinamento di base della mia select l'ho descritta sopra, ma poi
l'utente può fare quello che vuole, con i filtri e gli ordinamenti che
sceglie lui.
Lo farà di rado, quindi in quel caso passino anche le prestazioni (mica
posso fare un logico per ogni combinazione possibile!), ma questo permette
all'utente un'analisi veloce aggiungendo a programma le where e le order by
che sceglie l'utente, senza limiti (quasi) se non le informazioni che ho
nel SFL.

Grazie mille

P.S. Il programma poi gira in ambiente grafico WebGate, che mi permette di
rendere l'applicazione dinamica un modo esponenziale

[Stefano Tassi]

Post by MarcoP
Mi dilungo nel rispondere, perché l'analisi e le prove che sto facendo mi
risultano FONDAMENTALI per questo e per prossimi lavori...
Non saprei come spiegare quale valore aggiunto posso ricavare ottimizzando
le prestazioni di queste letture (un po' lo si capisce da quanto scrivo di
seguito).

Post by Stefano Tassi
il db2 non prevede l'order by nelle view
puoi però ovviamente gestirlo nel sqlrpgle

- anno e numero lavorazione
- anno/numero ordine/i a cui si riferiscono le lavorazioni

Post by Stefano Tassi
gli indici aiutano/risolvono problemi di performances.
considera che la view altro non è che una semplificazione della tua
query, in pratica ti evita di dover essere verboso nel programma ma non
fa nulla di più.
Se avevi necessità di indici prima (senza view) gli stessi indici ti
servono se usi una view.
tipicamente (ma un giretto di index advisor non fa male)
gli indici dovranno esistere per i campi di join e di where nelle
tabelle joinate, nelle where delle subselect, negli order by, ma ogni
query è una storia a sè stante; il suo utilizzo da parte del dbmanager
dipende da tanti fattori, non ultimo dalla numerosità della tabella.

E' qui che sono indeciso su come agire, anche perché non ho tutte le
conoscenze necessarie, e in pratica sto sperimentando adesso per dare più
performance al programma.
Mi spiego: nella view avevo fatto le classiche join di una select standard,
facendo riferimento a fles logici con indici e omissioni dei record
annullati, ma la create view non me lo permette perché vuole files fisici.
Quindi ho usato i fisici, e ho messo nella LEFT JOIN la condizione per
scartare gli annullati (non nella WHERE perché non devono essere scartati
record annullati del magazzino, che è il file principale, in conseguenza di
annullamenti sui files delle join).
Poi visto che la lettura dei dati risultava pesante, ho lanciato il mio
programma sotto debug per analizzare i messaggi dell'SQL, che, in pratica,
mi dice di creare degli indici/files logici come quelli che ho già, ma in
chiave vuole il flag di annullamento.

certamente, essendo nelle condizioni di where

Post by MarcoP
Sicuramente farò ulteriori prove per creare i logici che chiede, e
confrontare le prestazioni, ma metto in conto che ci possa essere una
strada più conveniente.

non creare logici, crea indici (create index)
sono *quasi* la stessa cosa

Post by MarcoP
Tempo fa (un paio di anni) qui si era parlato di parametri a livello di
sistema che davano prestazioni più performanti all'SQL rispetto al DB2 con
mille considerazioni possibili in base anche alla versione del sistema
operativo.
All'epoca ero limitato nelle decisioni, e lavoravo con un AS a V5R4, oggi
sono totalmente autonomo ed ho una V7R1. Cambia tutto sia per le scelte che
posso fare che per la versione dell'OS!

Post by Stefano Tassi
non togliere le decodifiche, tanto dovrai farle dopo con delle chaim,
non so quanto tu ci possa guadagnare.

Buono a sapersi, sia per l'uso di SQL che per le possibilità del programma!
L'ordinamento di base della mia select l'ho descritta sopra, ma poi
l'utente può fare quello che vuole, con i filtri e gli ordinamenti che
sceglie lui.
Lo farà di rado, quindi in quel caso passino anche le prestazioni (mica
posso fare un logico per ogni combinazione possibile!), ma questo permette
all'utente un'analisi veloce aggiungendo a programma le where e le order by
che sceglie l'utente, senza limiti (quasi) se non le informazioni che ho
nel SFL.
Grazie mille
P.S. Il programma poi gira in ambiente grafico WebGate, che mi permette di
rendere l'applicazione dinamica un modo esponenziale

[Dr.UgoGagliardelli]

Il 17.11.2017 13.31, Stefano Tassi ha scritto:
[...]

Post by Stefano Tassi
non creare logici, crea indici (create index)
sono *quasi* la stessa cosa

*quasi* *quasi* mi scappa da ridere
:-)

[Stefano Tassi]

Post by Dr.UgoGagliardelli
[...]

Post by Stefano Tassi
non creare logici, crea indici (create index)
sono *quasi* la stessa cosa

*quasi* *quasi* mi scappa da ridere
:-)

ciao Ugo,

ecco, sono senz'altro LF-keyed ma hanno qualche particolarità che li
differenzia, questo per dire che
senz'altro un LF fatto con crtlf può avere funzioni di index ma non è
classificato come index

ma parliamone ^_^

[MarcoP]

Post by Stefano Tassi

Post by Dr.UgoGagliardelli
[...]

Post by Stefano Tassi
non creare logici, crea indici (create index)
sono *quasi* la stessa cosa

*quasi* *quasi* mi scappa da ridere
:-)

ciao Ugo,
ecco, sono senz'altro LF-keyed ma hanno qualche particolarità che li
differenzia, questo per dire che
senz'altro un LF fatto con crtlf può avere funzioni di index ma non è
classificato come index
ma parliamone ^_^

Ho verificato le prestazioni (e i messaggi di debug di SQL) senza la
creazione di flogici o index, con gli index, o con LF.
Praticamente sono identiche, anzi parrebbe che con i files logici sia meglio,
anche se di poco.

Inoltre le chiavi che mi propone il debug SQL sono (per me) in un ordine
logico diverso (es. per me ANNO-NUMERO-PROGRESSIVO, per SQL PROGRESSIVO-ANNO-
NUMERO), e se specifico un ordine di chiavi diverso nei miei index/LF non li
usa e ne crea di nuovi... Tempo perso, visto che le chiavi vanno usate
comunque tutte (?)

Anche la creazione di index con in chiave i flag di omissione sembrano un "di
più" che non giova. Non posso sfruttare i miei LF nelle VIEW?

E' possibile evitare questi problemi? Il file QAQQINI e l'uso di SQE (ho
rispolverato una risposta di Obelix ad un mio post di gennaio dell'anno
scorso) possono aiutarmi in qualche modo? Il mio (come accennato sono a V7R1)
è in QSYS e ha tutti i valori a "*DEFAULT".

Grazie

[Stefano Tassi]

Post by MarcoP

Post by Stefano Tassi

Post by Dr.UgoGagliardelli
[...]

Post by Stefano Tassi
non creare logici, crea indici (create index)
sono *quasi* la stessa cosa

*quasi* *quasi* mi scappa da ridere
:-)

ciao Ugo,
ecco, sono senz'altro LF-keyed ma hanno qualche particolarità che li
differenzia, questo per dire che
senz'altro un LF fatto con crtlf può avere funzioni di index ma non è
classificato come index
ma parliamone ^_^

Ho verificato le prestazioni (e i messaggi di debug di SQL) senza la
creazione di flogici o index, con gli index, o con LF.
Praticamente sono identiche, anzi parrebbe che con i files logici sia meglio,
anche se di poco.

più che i messaggi di debug dovresti consultare l'index advisor del
navigator: fornisce informazioni più puntuali.

Post by MarcoP
Inoltre le chiavi che mi propone il debug SQL sono (per me) in un ordine
logico diverso (es. per me ANNO-NUMERO-PROGRESSIVO, per SQL PROGRESSIVO-ANNO-
NUMERO)

se la tua query aggancia anno.numero-progressivo con l'operatore =
la cosa non cambia.

, e se specifico un ordine di chiavi diverso nei miei index/LF non li

Post by MarcoP
usa e ne crea di nuovi... Tempo perso, visto che le chiavi vanno usate
comunque tutte (?)

non creare LF, crea indici

Post by MarcoP
Anche la creazione di index con in chiave i flag di omissione sembrano un "di
più" che non giova.

a volte l'ottimizzatore richiede la presenza di indici per verificare i
contenuti; li usa nell'ottimizzazione ma non nell'implementazione della
query.


Non posso sfruttare i miei LF nelle VIEW?
le view accettano tabelle, non lf

Post by MarcoP
E' possibile evitare questi problemi? Il file QAQQINI e l'uso di SQE (ho
rispolverato una risposta di Obelix ad un mio post di gennaio dell'anno
scorso) possono aiutarmi in qualche modo? Il mio (come accennato sono a V7R1)
è in QSYS e ha tutti i valori a "*DEFAULT".
Grazie

[MarcoP]

Post by Stefano Tassi
se la tua query aggancia anno.numero-progressivo con l'operatore =
la cosa non cambia.

Resta il problema che mi scarta quello che ho creato e ne crea di nuovi

Post by Stefano Tassi
non creare LF, crea indici

Li ho provati entrambi, prima LF e poi index, e verificato le prestazioni
alla prima apertura del programma, e alla seconda...

Post by Stefano Tassi
le view accettano tabelle, non lf

L'unica cosa che ho capito bene :-)

Mi sa che alla fine i problemi di base sono 2:
- una view che coinvolge tanti archivi
- conoscenza di SQL (mia) limitata solo ad alcune funzioni

Fatto sta che mi sta portando via più tempo del previsto (e di quanto ne
posso spendere), quindi riprenderò in mano questa cosa più avanti...

Intanto grazie per le risposte

[Obelix]

Post by MarcoP
- una view che coinvolge tanti archivi
- conoscenza di SQL (mia) limitata solo ad alcune funzioni

"La complessita' di un programma si espande fino a raggiungere i limiti
del programmatore, e poi ancora un po'" (c) Murphy's Law

[MarcoP]

Post by Obelix
"La complessita' di un programma si espande fino a raggiungere i limiti
del programmatore, e poi ancora un po'" (c) Murphy's Law

Altrimenti dove sarebbe il bello ?!?

(c) MarcoP
:-)