Discussion :

[beretb]

Bonjour à tous,
Afin de changer de version d'Oracle (Standard 12 vers Entreprise 12), un nouveau serveur Windows 2012 R2 hébergeur a été mis en place ; il est à noter que les serveurs ont été déployés avec les mêmes paramètres et en 64 bits.

Nous sommes en phase de validité, et je rencontre un problème avec un script Powershell qui fonctionnait parfaite avec le serveur (2012 R2 lui aussi) et la base précédente.
Ci-après un extrait du code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
	$connectionString = 'Data Source=' + $machine + ':' + $portOracle+ '/' + $nomInstance + ';uid=' + $credential.GetNetworkCredential().username + ';pwd='+ $credential.GetNetworkCredential().Password + '; unicode=false';
	
	# Déclaration de la connexion ORACLE
	$oracleConnection = new-object System.Data.OracleClient.OracleConnection($connectionString);

	$cmd = new-object System.Data.OracleClient.OracleCommand;
	$cmd.Connection = $oracleConnection;

	# Déclaration de la procédure stockée retournant l'information
	$cmd.CommandText =   $fonctionRepertoire;	
	$cmd.CommandType = [System.Data.CommandType]::StoredProcedure;


	$cmd.Parameters.Add("P_RETOUR", [System.Data.OracleClient.OracleType]::Varchar,4000)  | out-null;	
	$cmd.Parameters["P_RETOUR"].Direction = [System.Data.ParameterDirection]::Output;
	
        # Ouverture de la connexion
	$oracleConnection.Open();
			   
	# Appel de la procédure stockée 
	$cmd.ExecuteNonQuery() | out-null;

	# Fermeture de la connexion
	$oracleConnection.Close();

       # Recupération de la valeur en retour
       $retour= $cmd.Parameters["P_RETOUR"].Value;


#Pour information
write-host "valeur de retour : $retour" -foregroundcolor yellow;

Si j'exécute le script sur l'ancien serveur, j'obtiens : "c:\Transit"
Alors que sur le nouveau, j'ai : "c:\Tr"


Si je modifie la donnée que doit retourner la base : ex : "c:\Zone_de_Transit\Pour_essayer"
Sur l'ancien serveur, c'est bon,
par contre sur le nouveau j'obtiens : "c:\Zone_de_Tran"

En fait, il me retourne grosso-modo la moitié des caractères attendus ; (15 au lieu de 31) ; Problème de polices d'échanges ???

J'ai testé les versions de Powershell via ce script:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$Arch = (Get-Process -Id $PID).StartInfo.EnvironmentVariables["PROCESSOR_ARCHITECTURE"];
if ($Arch -eq 'x86') {
    Write-Host -Object 'Running 32-bit PowerShell';
}
elseif ($Arch -eq 'amd64') {
    Write-Host -Object 'Running 64-bit PowerShell';
}

Running 64-bit PowerShell sur les deux machines...

J'ai aussi vérifié le paramétrage des caractères des bases ,ils sont identiques...

-----------------------------------------------------------------------------------
Petit complément sur la problématique, suite à de nouveaux tests.

Si je réduit la zone de réception de la variable "P_RETOUR", en deçà de 31 (dernier exemple), la procédure Oracle se met en erreur ; ce qui est logique et semble indiqué que la solution se situe dans la récupération par Powershell de la valeur.
Par contre, ce qu'il faut faire ???

-----------------------------------------------------------------------------------

On continue dans les tests !

J'ai dupliqué le script sur le serveur initial en le laisant pointé sur la nouvelle base Oracle
résultat : C'est ok
J'obtiens bien la totalité de la donnée
=> le problème se situe au niveau de l'interprétation du retour par Powershell sur le nouveau serveur

petite précision, le client Oracle étant en 64 bits, le script tourne sur Powershell 64 bits.


-----------------------------------------------------------------------------------
En conclusion :

AU SECOURS !!! Je suis largué.

D'avance, merci pour votre aide.

[Laurent Dardenne]

Salut,
recherche avec ces mot-clés 'c# oracle truncated result OracleConnection'.
A voir aussi
Est-ce la version du framework dotNET qui poserait problème ?

[beretb]

Bonjour Laurent et surtout merci.

J'avais bien recherché coté English mais pas avec les bon mot clés.

Conclusions de la recherche : Bug coté du client Oracle 12 et pour moi c'est un peu la cata.. car les solutions envisageables sont :

- 1 - Modifier la version du client (apparemment la 11 en 64 bit est ok) mais pour moi impossible car il dépend directement de la base et est exploité par un logiciel tiers (ERP).

- 2 - Modifier la fonction appelée de manière à retourner un autre type de donnée, mais cette fonction est aussi appelé par d'autres programmes qui n'ont pas le problème (appels php)

Contre mesure à mon défaitisme :

- 3 -C'est la solution parfaite (trouvée sur un forum Microsoft) ; le plus marrant (si l'on peut dire), c'est que le problème fût déjà présent en 2005...

Elle consiste à déclarer la zone de réception, non pas en varchar, mais en clob, puis à la convertir en string, ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

...
         $cmd.Parameters.Add("P_RETOUR", [System.Data.OracleClient.OracleType]::Clob)  | out-null;	
         $cmd.Parameters["P_RETOUR"].Direction = [System.Data.ParameterDirection]::Output;

        # Ouverture de la connexion
	$oracleConnection.Open();
			   
	# Appel de la procédure stockée 
	$cmd.ExecuteNonQuery() | out-null;

	# Fermeture de la connexion
	$oracleConnection.Close();

       # Recupération de la valeur en retour
       $retour= $cmd.Parameters["P_RETOUR"].Value.Value.ToString();

...

Merci, à l'illustre inconnu rodrigoshoto ( lien vers la solution en c# :https://social.msdn.microsoft.com/fo...ored-procedure ) mais aussi à tous ceux qui ont pris la peine de lire mon problème.


Bon week end à tous.