Query verso Oracle

Navigation:  APPENDICI >

Query verso Oracle

Previous pageReturn to chapter overviewNext page

Può capitare che qualche Cliente abbia problemi ad interrogare con IrionEDM i DB Oracle perché i risultati ritornati non sono quelli attesi oppure esce un errore di tipo ORA-01722.

Di solito questo è dovuto al fatto che da Oracle ci espongono una vista che al suo interno effettua confronti tra colonne di tipo non omogeneo (tipicamente numero vs. stringa o data vs. stringa); normalmente chi gestisce le interrogazioni su Oracle decide in modo arbitrario che le impostazioni di language del client e del server siano concordi e quindi non si preoccupa di forzare la locale ad inizio esecuzione.

Purtroppo però Oracle sovrascrive le impostazioni del server con quelle del Client, se presenti, e quindi la stringa “12345.67” che in impostazioni US è considerata valida quando viene confrontata con un numero, con impostazioni IT dà errore.

 

Esiste modo per capire quali siano le impostazioni su client e server.

La query seguente può essere eseguita tramite dblink di tipo Oracle:

 

-- legge le impostazioni di globalizzazione della sessione corrente

SELECT * FROM (

SELECT 'Database' AS "LEVEL", p.* FROM nls_database_parameters p

UNION ALL

SELECT 'Session' AS "LEVEL", p.* FROM NLS_SESSION_PARAMETERS p

UNION ALL

SELECT 'Instance' AS "LEVEL", p.* FROM nls_instance_parameters p

) t

WHERE t.parameter IN ('NLS_NUMERIC_CHARACTERS','NLS_LANGUAGE')

 

A questo punto si può intervenire uniformando le variabili d’ambiente tra client(s) e server. Questo però vuol dire che le interrogazioni Oracle potranno ritornare risultati discordanti rispetto alla Locale del pc che sta facendo le query. Altro side-effect è che, al variare minimo delle impostazioni del client, non funziona più nulla.

 

La soluzione migliore, però, sarebbe intervenire a monte:

1.Forzando l’NLS_LANGUAGE a quello corretto in ogni vista e function che può incorrere nel problema

2.Tipizzando correttamente le colonne che contengono numeri e date in modo da evitare completamente qualsiasi necessità di forzare NLS_LANGUAGE a livello di query o di variabile d’ambiente.