Compatibilità con Oracle 12

[davide.baraghini]

Non ho trovato informazioni relativamente al supporto alla versione 12 di Oracle.
Ho visto che è stata creata l'attività NPQ02863 per tenere conto di una conversazione di Agosto sul forum sullo stesso tema.
viewtopic.php?nomobile=1&f=2&t=71730
Volevo sapere se siete riusciti a procedere con i controlli e a che punto è l'attività.

[teopost]

+1

[lucabaldini]

Non abbiamo ancora analizzato l'attività. Però, visto che siamo qui, se utilizzate Oracle 12 cosa non funziona oggi? In altre parole, cosa manca per supportare Oracle 12 nelle librerie? Forse c'è già quasi tutto...

[teopost]

La cosa piu' interessante secondo me riguarda non tanto il subset di comandi sql e plsql che INDE utilizza (quelli, per compatibilita' sono sempre funzionanti anche con le ultime versioni di Oracle), ma la possibilità di utilizzare il driver Managed .NET di Oracle.

http://www.oracle.com/technetwork/topic ... 85163.html

Come sai l'attuale driver Oracle usato da INDE si basa sulle OCI.
Per questo motivo una applicazione INDE a 32 bit puo' usare solo il client a 32.
Una a 64 invece funziona solo col client Oracle a 64 bit.

Questa è un po una seccatura perchè spesso sei costretto a installare il client 2 volte e a farli convivere (quella a 32 e quella a 64) in quanto i server non sempre ospitano solo le tue applicazioni.

A partire dalla versione 12 di Oracle tuttavia e' possibile utilizzare un client interamente sviluppato col framework .NET.
Questo ti permette di deployare una applicazione che ha gia', nella sua cartella di binari, tutto ciò che gli serve per funzionare senza neanche installare il client.
Inoltre funziona sia a 32 che a 64 bit.

Noi usiamo questo driver già da un po di tempo su alcune applicazioni (ovviamente non INDE).

L'utilizzo del client Managed risolverebbe anche il problema dell'IDManager.

Si veda : viewtopic.php?f=2&t=75918

[lucabaldini]

Non ho capito. Le app prodotte con InDe non sono né a 32 bit né a 64 bit.... a meno che:
- non utilizzino i grafici (e in quel caso viene inclusa automaticamente varie DLL che ci sono solo a 32bit)
- non utilizzino SQLite lato server (e in quel caso viene inclusa la System.Data.SQLite.dll)
- non utilizzino FTP o altro (e in quel caso viene inclusa la ChilkatDotNet2.dll)

Se non sono questi i casi le app vanno sia a 32 che a 64 bit.

Ora, il connector di Oracle non è re-distribuibile (non lo è mai stato) quindi non posso includerlo nell'installatore di InDe. Pertanto se una app utilizza Oracle InDe utilizza automaticamente il driver Oracle di Microsoft (quello che in .NET di chiama "System.Data.OracleClient.OracleConnection").
Però, prima di utilizzare quello "standard" di Microsoft prova a vedere se è in grado di utilizzare quello di Oracle (che si chiama "Oracle.DataAccess.Client.OracleConnection"). Se riesce a caricare quella classe usa quella, altrimenti usa quella di Microsoft (e nel DEBUG è evidenziata quale delle due sta utilizzando l'applicazione).

Ora, se nella BIN dell'applicazione (o nella GlobalAssemblyCache del server) è installato il connector .NET di Oracle le app prodotte con InDe utilizzano quel connector.

Detto questo, non mi è chiaro perché non si può utilizzare la nuoav versione del connector Oracle in una applicazione .NET. Dovrebbe essere sufficiente scaricare dal sito di oracle il connector .NET, aggiungerlo alla custom dell'applicazione (perché vada nella Bin) e poi dovrebbe andare, sia a 32 che a 64 bit... se il connector .NET funziona per entrambe le architetture... Almeno così è come capisco io il problema... Ma magari c'è altro...

[teopost]

Quando ho usato io il managed client oracle, ho dovuto da codice aggiungere la reference e la using per uno specifico namespace (using Oracle.ManagedDataAccess.Client)
Scusa l'ignoranza ma come fa inde a sapere questo se non contiene questi 2 riferimenti ?

[lucabaldini]

Ah, ora mi è chiaro... Oracle ha introdotto un nuovo namespace senza utilizzare quello esistente... fico... il mondo è complicato anche grazie a loro... :-)

A questo punto dovrei studiare l'interfaccia e sperare che estendano la classe base IDbConnection (così come fanno quasi tutti i driver .NET)... Se estendono IDbConnection potrei provare prima a cercare Oracle.ManagedDataAccess.Client.OracleConnection... se non trovo quella posso provare con Oracle.DataAccess.Client.OracleConnection e, se non c'è nemmeno quella, vado con System.Data.OracleClient.OracleConnection...

Vabbè... non potevano usare lo stesso nome del "vecchio" driver così che uno poteva semplicemente sostituire la DLL e l'app andava? Troppo semplice.... meglio obbligare la gente a riscrivere parti di app... è più fico... :-(

[lucabaldini]

Ho creato l'attività NPQ03134 per tenere conto di questa conversazione. Quando verrà valutata, potrai seguirne l'andamento con Instant Developer Roadmap.

[lucabaldini]

Così ad occhio sembra che l'interfaccia degli oggetti sia la stessa

( https://docs.oracle.com/cd/E48297_01/doc/win.121/e41125/intro003.htm#BHCJFIAJ )

Forse è davvero sufficente provare a cercare entrambi i namespace e vedere chi c'è... poi usare quello trovato... Forse non ci vuole troppo...

[lucabaldini]

Ho visto ora la tua domanda:

Scusa l'ignoranza ma come fa inde a sapere questo se non contiene questi 2 riferimenti ?

Io non posso scrivere in alto "using Oracle.ManagedDataAccess.Client" perché non è detto che tutti l'abbiano. Quindi in alto ho scritto "using System.Data.OracleClient;" (quello c'è sempre). Poi, quando devo aprire la connessione provo a caricare un Assembly per nome. Se riesco a trovarlo, tramite l'assembly (e quindi con la reflection) provo a cercare la classe che mi serve e la uso. In altre parole utilizzo una sorta di "Lazy Binding"... non referenzio mai direttamente classi di Oracle ma le cerco sempre tramite reflection... così posso usarle se ci sono e non usarle (con un fallback su quelle Microsoft) al bisogno...