Le mie avventure con Oracle e l'Oracle Data Provider non sono finite. Alcune cose che ho scoperto oggi:
1) Il metodo che ha Oracle di registrare gli oggetti nella GAC e come questi vengono referenziati da .Net è sostanzialmente mistico. Nel senso che ci vuole la pazienza di un santo per non incartarsi. Attualmente esiste una sola versione di Orale Data Provider per .Net (il prodotto chiamato normalmente ODP): la 10.0.4. Sul mio notebook di sviluppo ho installato un server Oracle e, dato che a casa avevo fretta ed i CD "ufficiali" erano in ufficio, ci ho installato Oracle 10g R2 di cui avevo un CD mandatomi da Oracle. Bene, il risultato è che qualunque cosa compilata sul mio notebook non ne vuole più sapere di andare su nessun altro PC dell'azienda, anche se l'ODP è lo stesso. Lezione imparata, sulla macchina di Build ho religiosamente installato solo l'ODP corretto ed almeno le robe buildate e rilasciate vanno perfettamente.
2) Se iniziate a vedere degli errore "Specified cast is not valid" potete tranquillamente iniziare a pregare, sempre perchè si deve essere mistici. Ci ho perso 2 ore ed il tutto succede perchè c'era un metodo che settava la proprietà ArrayBindCount di un OracleCommand e non la resettava, la chiamata successiva non usava variabili di questo tipo ed il risultato era l'errore in questione. Assolutamente non parlante e poco chiaro, ma anche qui lezione imparata: quando usate un OracleCommand è buona cosa, se questo non è locale ad una funzione, includerlo in un blocco Try...Finally e nella Finally provvedere a resettarlo (Parameters.Clear, ArrayBindCount=0 e così via)
3) Attenzione ad usare la fantastica feature "where RowID < 2" per fare l'equivalente di una TOP 1. Il RowID viene calcolato e gestito PRIMA di fare una Order By. Anche questa cosa nota, ma ci ho perso 2 ore buone. Lezione imparata: non appena vedete la parola chiave RowID... fate attenzione
4) Anche questa è vecchia ma ve la riporto: attenzione alle tabelle temporanee. In SQL quando fate la close di una connection e questa viene rimessa nel pool le tabelle temporanee spariscono, con Oracle no. Quindi è necessario creare le tabelle temporanee nel modo giusto (ON COMMIT DELETE ROWS, notate anche che non è possibile creare tabelle temporanee da codice ma devono essere inserite nello Schema del database) ed usare le Transaction anche in sola lettura per gestire la cosa (oppure date una delete prima della close, sempre usando una bella Try...Finally, però mi piace meno).
Insomma, Oracle continua a piacermi sempre di meno, ma vedo la fine del tunnel.
La cosa impressionante (e va detto) è che a database e stored procedure assolutamente NON ottimizzati (solo gli indici di PK e FK definiti, nessun indice ausiliario, SP portate e basta, senza ottimizzazioni specifiche per usare feature sofistiche di plsql) sullo stesso ambiente (stessi DB server che vanno sulla stessa SAN) le performance sono già di un 10% migliori di SQL Server 2000 (sia come concorrenza che come performance pura). Prima o poi mi toglierò la curiosità di fare le stesse prove con SQL 2005, speriamo che MS abbia recuperato il gap.