ERROR [NA000] [Microsoft][ODBC driver for Oracle][Oracle]ORA-06413: Connessione non aperta. Risolto

Quando si verifica?
Nella maggior parte dei casi si verifica quando da un web service pubblicato su un II7.# si tenta di accedere ad un driver odbc realizzato a 32 bit.
Ci sono Workaround Noti?
Facendo parecchie ricerche emergono "estenuanti affermazioni inutili" come
-Associare a utenze diritti vari...
-Spostare programmi in cartelle varie...
-Utilizzare prodotti di terze parti...

Ma nessuno di questi funzioni o è la suoluzione effettiva, perchè il problema non è li...

Risoluzione per windows 7
A) assicurarsi di aver realizzato un odbc a 32 bit
-Accedere a c:/windows/siswow64/odbcad32.exe
-Creare un odbc per Oracle Microsoft ODBC for Oracle

B) assicurarsi di aver compilato la propria soluzione (progetto per progetto) con:
-Framework 2.0
-cpu X86

C) aprire "Gestione Internet Information Server"
-Scegliere: Pool di applicazioni
Aggiungere quindi un nuovo pool con le specifiche come da immagine:


Accertarsi che la voce "ATTIVA APPLICAZIONI A 32 bit " sia a TRUE

D) pubblicare la propria soluzione



E) Tornare su IIS e configurare la soluzione per l'appPool appena creato
-Selezionare il gruppo di appPool
-Verificare fra le proprietà degli appPool le applicazioni associate
(Dovrebbe trovarsi sotto DEFAULT APPPOOL)
-Selezionare default apppool
-Selezionare il link dal blocco di destra Visualizza Applicazioni
-Doppio Click sull'applicazione



-Tornare alla soluzionee verificare che eventuali referenze al web service realizzato, puntino
al web service pubblicato.

Esito
In questo modo si ha la certezza che il Web Service sia Eseguito in modalità 32 bit, dall' IIS,
va da se che deve essere compilato a 32 bit.

Se al termine di questo processo si ottiene ancora lo stesso errore possono essersi verificati due
problemi .
a) IIS non ha visto le modifiche (conviene riavviare tutto - macchina compresa)
b) non tutte le web reference sono state aggiornate.

Note conclusive
Questo problema esiste da quando esiste IIS a 64 bit, tuttavia non sono documentati i processi per ottimizzare il sistema a lavorare in piena compatibilità con le applicazioni a 32 bit.

-Potrebbe essere necessario aver installato il client di Oracle in program files (x86).
-Alcuni set up di Oracle client potrebbero non accettare spazie e parentesi nei nomi.

Foreach (xmlNode in xmlDocument.childNodes) non va...

Sembra strano .. ma c'e' una possbilità di Bug....

Fate questa prova createvi un xml che abbia quest'aspetto:
Coordinate
coordinata
x = 1
y= 1

coordinata
x = 2
y= 2

coordinata
x = 3
y= 3

coordinata
x = 4
y= 4


Poi provate a scrivere un banalissimo :
xmlDocument xd = new xmlDocument()
xd.Load([l'xml che avete ralizzato])

foreach (xmlNode xN in xd.childNodes)
{
console.writeline ( xN.InnerText);
}

che cosa succede ??

Potrebbe essere che anche a voi capiti di vedere sempre il primo nodo ??
si credo che possa succedere... ora fate questa prova ...

for (int i = 0; i < xd.childNodes.count; i++)
{
xmlNode xN = xd.childNodes[i];
console.writeline ( xN.InnerText);
}

acc.. succede ancora la stessa cosa ??

for (int i = 0; i < xd.childNodes.count; i++)
{
xmlNode xN = xd.childNodes[i].clone();
console.writeline ( xN.InnerText);
}

Tho' va che bello così funziona ??

Le supposizioni che si possono fare sono tante .. tuttavia solo con il clone il cursore sugli elementi si sposta.. caso contrario no...

Che sia un bug ??

Ecco un bel esempio di come togliersi dai guai.

Quante volte ci è capitato di dover accedere ad un componente esterno (realizzato da altri) che non ha un interfaccia condivisa ho condivisibile... e quindi non poterlo sfruttare al meglio ??

A me capita spesso.... ma questo caso mi sono fatto più furbo che tecnico...

using System;
using System.Collections.Generic;

namespace Test
{
// interfaccia
public interface IWsDerived
{
string DerivedMethod(string text);
}

// costruttore
public class WsConcrete
{
// modello primario
public IWsDerived GetDeploy(int model)
{
if (model == 1) { return new coModelA(); }
if (model == 2) { return new coModelB(); }
}

// modello non in uso
public IWsDerived GetTest()
{

}
}

// componente "a" che non implementa l'interfaccia
public class ModelA
{
public string DoMoreAboutIt(string message)
{
return message + "| Done";
}
}

// componente "b" che non implementa l'interfaccia
public class ModelB
{
public string DoMoreText(string message)
{
return message + "| Text Done";
}
}

// wrapper (+ o -) per modello A
public class coModelA : IWsDerived
{
public string DerivedMethod(string Message)
{
ModelA a = new ModelA();

return a.DoMoreAboutIt(Message);
}
}

// wrapper (+ o -) per modello B
public class coModelB : IWsDerived
{
public string DerivedMethod(string Message)
{
ModelB b = new ModelB();

return b.DoMoreText(Message);
}
}
}


Model A e Model B immaginateli come blocchi esterni...
All'interno del mio processo diventano accessibili tramite l'interfaccia...

Scritto e compilato !!

ToOdbcDataType

Bene .. bene bene... dato che non credo di essere l'unico a litigare con Odbc nel realizzare un breve data provider mi sono visto costretto a realizzare anche questo simpatico oggettino....

Diciamo che è la base o il punto di partenza per la conversione fra un generico DBType e un OdbcDataType...

partendo da questo link "http://msdn.microsoft.com/en-us/library/bbw6zyha%28VS.71%29.aspx" che mamma microsoft ha ben pensato di pubblicare...
ho realizzato questo "mini" data converter..

private OdbcType ToOdbcDataType(DbType Type)
{
switch (Type.ToString())
{
case "AnsiString": return OdbcType.VarChar;
case "Boolean": return OdbcType.Bit;
case "Byte": return OdbcType.TinyInt;
case "Binary": return OdbcType.VarBinary;
case "Date": return OdbcType.Date;
case "DateTime": return OdbcType.DateTime;
case "Decimal": return OdbcType.Numeric;
case "Double": return OdbcType.Double;
case "Single": return OdbcType.Real;
case "Guid": return OdbcType.UniqueIdentifier;
case "Int16": return OdbcType.SmallInt;
case "Int32": return OdbcType.Int;
case "Int64": return OdbcType.BigInt;
case "String": return OdbcType.VarChar;
case "Time": return OdbcType.Time;

}
return OdbcType.VarChar;
}

Ipoteticamente il Valore di ritorno di default andrebbe gestito meglio .. ma l'occasione fa l'uomo "furbo"...

Configuration 64 bit vs 32 bit

Ed è bene parlare anche di questo... ad oggi si presentano alcuni problemi nuovi, e più complessi da gestire.
Fra i tanti ( contro cui dobbiamo già combattere... ) si presenta anche
Realizzare un applicazione a 32 su un archittettura a 64 ...

Visual studio 2008 presenta nelle propietà della nostra soluzione nel pannello build il
platform target dove possiamo scegliere anyCPU, X86 , X64
Sia per le soluzione in Relase, sia per le soluzioni in Debug.

Tuttavia questo non sempre è sufficiente...

Se per esempio utilizzate un ODBC pensato per X86 su una soluzione X64 vi prenderete una bella eccezione
per differenti architetture...
Già in questo blog ho argomentato un problema simile per Oracle...
cmq prima di lanciare odb32 ... lanicate C:\Windows\SysWOW64\odbcad32.exe che è quello vero.

Ancor più complesso e comprendere che cosa succede nelle soluzioni Web, dove è necessario realizzare
un pool AdHoc per le soluzioni a 32 bit.
E credetemi confiugrare il nuovo ISS, se siete abituati al vecchio, è un po complesso, non difficile
ma complesso.
Tanto è che il più delle volte sarete costretti a pubblicare la vostra soluzione...

Se poi dovete realizzare il setup di quello che avete prodotto e vi serve un framework precedente...
ancora una volta dovrete litigare un po per scoprire che se nel vostro pacchetto appare l'inclusione
del frame work, dovrete fare doppi click sull'icona e dalla finiesrtra delle proprietà settare
l'effettiva versione.

Oppure tramite doppio click sul progetto di setup e da proprietà settare il terget...

Network is Up or Down

Una delle situazioni ricorrenti nella programmazione client server è la disponibilità della rete... Effettivamente ci sono tanti (troppi) modi per comprendere se l'accesso ad una lan è ancora disponibile.

Di fatto c'e' una possibilità semplice semplice che ci costringe a lavorare bene e a far poca fatica:

nel namespace :System.Net.NetworkInformation abbiamo una classe che fa al caso nostro; la
NetworkChange.

Questa consente di delagare un evento sullo stato di Change della rete...

NetworkChange.NetworkAvailabilityChanged += NetworkAvailabilityChanged;

il delegato potrebbe quindi avere quest'aspetto :

private void NetworkAvailabilityChanged(object sender, NetworkAvailabilityEventArgs e)
{
if (e.IsAvailable)
{
// la rete è su
}
else
{
// la rete è giù
}
}

Ed ecco come 5/6 righe di codice rendono semplice semplice , l'arduo compito di comprendere
se il client può contattare il server..

Casi di studio D.d.d

Vi siete mai posti la domanda, " ma perchè non raccogliere tutte le attività di un azienda in un unica soluzione ?"...

Io si ma effettivamente la risposta a questa domanda è frammentata in troppe porzioni, tuttavia c'e' una buona possibilità di poter comprendere quanto è necessario fare per poter dare una risposta significativa a questa ardua domanda.

Nel mio caso di studio (in sunto questo... ) ho raccolto alcune delle informazioni base per poter implementare una soluzione D.D.D.

La base comune è il domino ossia l'azienda XYZ, questa per vivere scambia materiale fra due paesi differenti, gestisce ordini e magazzino... e in tutto questo ci sono persone che vi lavorano.

E' possibile che persone del paese A debbano poter accedere a informazioni del paese B.

Appare chiaro che nei due paesi esistano due filiali differenti, con persone differenti...

In questo breve esempio si comprende quanti potenziali progetti potranno essere realizzati,
e quanti di questi potranno avere aspetti differenti.
Un ipotesi e che dal paese A, la risorsa 1 richieda di vedere il magazzino o la giacenza o un elemento specifico del paese B...

Da qui l'idea di realizzare due front-end diversi per il magazzino un Web, e uno desktop, in modo che possa essere condiviso, da cui non è difficile comprendere che la risorsa 1 acceda da web, ad un sito che espone i dati del magazzino del paese B.

Ora è quindi necessario che a livello di XYZ (l'azienda) esista una rappresentazione unica di tutte
le risorse, indipendentemente da dove queste siano dislocate.

Non dimentichiamoci che i paesi potrebbero essere di differente cultura, e che quindi gli utenti del paese A parlino una lingua diversa dal paese B.

Per Aggregazione sarà doveroso aggiungere all'immutable risorsa 1 anche la provenienza, o eventuali profili per cui accedere alla soluzione.

Il mio dubbio in tutto questo era la posizione fisica della fonte dati, ma partendo dall'univocità di un utente e da una corretta profilazione, si può supporre di accedere (facade) ai sotto sistemi
sfruttando solo le loro basi dati.

Filosofia forse... o frose no, solo un caso di studio.