Oracle.DataAccess.Client procédure stockée ORA-01403

Bonsoir,

Microsoft ayant annoncé que System.Data.OracleClient ne serait plus maintenu dans les futures versions du FrameWork, j'ai essayé de remplacer ce pilote par Oracle.DataAccess.Client après avoir installé ODT.

L'appel à une procédure stockée provoque l'erreur suivante :

Citation:

---

ORA-01403: aucune donnée trouvée
ORA-06512: à "SCHEMA.MA_FONCTION", ligne 15
ORA-06512: à ligne 1
Oracle Data Provider for .NET
à Oracle.DataAccess.Client.OracleException.HandleErrorHelper(Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, String procedure, Boolean bCheck)
à Oracle.DataAccess.Client.OracleException.HandleError(Int32 errCode, OracleConnection conn, String procedure, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, Boolean bCheck)
à Oracle.DataAccess.Client.OracleCommand.ExecuteNonQuery()

---

Or la même procédure stockée dans la même application fonctionnait parfaitement avec OracleClient!
Quelqu'un a-t-il une idée ?

Merci d'avance

Oui, enfin il y a deux problèmes (le deuxième étant révélé par le premier :D ) :

- le premier est très certainement un problème de paramètres. Par défaut, le provider Oracle traite les paramètres par rang et non par nom; pour remettre le comportement du provider Microsoft (traitement par le nom), penser à mettre dans les commandes Oracle la propriété BindByName à true.

J'ai déjà eu ce problème : http://www.developpez.net/forums/d10...pel-proc-stoc/


- l'erreur que tu obtiens revèle aussi l'absence de traitement de l'exception "no data found" dans la programmation de ta proc stoc. En PL/SQL, un SELECT ... INTO .. lève une exception si aucune donnée n'est trouvée.

Bonjour,
Bingo ! That's it
C'est d'autant plus surprenant que le passage de paramètres par noms est plutôt une habitude Oracle que Microsoft me semble-t-il.
Qui plus est je n'ai pas vu cette propriété mentionnée dans les exemples donnés par Oracle.
Evidemment le no_data_found n'était que la conséquence de l'inversion probable des paramètres, j'aurai dû y penser plus tôt !

Enfin merci pour votre réponse et passez de bonnes fêtes !

Parfait. Ne pas oublier le bouton :resolu:

Citation:

---

Envoyé par clem_alain

C'est d'autant plus surprenant que le passage de paramètres par noms est plutôt une habitude Oracle que Microsoft me semble-t-il.

---

Autant que je m'en souvienne, ADO.NET depuis sa première version a toujours eu les binding by name par défaut.

Citation:

---

Envoyé par Bluedeep

Autant que je m'en souvienne, ADO.NET depuis sa première version a toujours eu les binding by name par défaut.

---

Il me semble aussi, du moins pour les SGBD qui le supportent...

Citation:

---

Envoyé par Bluedeep

Parfait. Ne pas oublier le bouton :resolu:



Autant que je m'en souvienne, ADO.NET depuis sa première version a toujours eu les binding by name par défaut.

---

Oui, c'est bien ce que je disais avec les pilotes Microsoft que ce soit OracleClient ou MSDAORA.1 j'ai toujours passé mes paramètres par noms !
Le plus bizarre c'est qu'Oracle est plus coutumier du fait, par exemple dans SqlDeveloper la génération d'un bloc anonyme pour appeler une procédure stockée utilise systématiquement l'appel par noms !
Bôf, "Ces mystères nous dépassent, feignons d'en être l'instigateur !"

Cette "subtilité" (pour être poli) du provider Oracle est d'ailleurs particulièrement énervante quand on veut utiliser la couche d'abstraction d'ADO.NET (DbProviderFactory & co), parce qu'on est obligé de faire un truc spécifique pour Oracle... Dommage qu'il n'y ait pas un paramètre global genre BindByNameByDefault :?

Citation:

---

Envoyé par tomlev

Cette "subtilité" (pour être poli) du provider Oracle est d'ailleurs particulièrement énervante quand on veut utiliser la couche d'abstraction d'ADO.NET (DbProviderFactory & co), parce qu'on est obligé de faire un truc spécifique pour Oracle... Dommage qu'il n'y ait pas un paramètre global genre BindByNameByDefault :?

---

D'une manière générale, il manque au sujet des paramètres quelque chose dans la couche d'abstraction : un "ParameterNameFactory", du fait que justement le nommage des paramètres n'est pas standard (par exemple @param ou SQL SERVER, :param pour Oracle, et je ne sais pas trop quoi pour les autres).

Ceci permetrait d'écrire des requêtes en norme SQL standard quel que soit le type de SGBD.

Citation:

---

Envoyé par Bluedeep

D'une manière générale, il manque au sujet des paramètres quelque chose dans la couche d'abstraction : un "ParameterNameFactory", du fait que justement le nommage des paramètres n'est pas standard (par exemple @param ou SQL SERVER, :param pour Oracle, et je ne sais pas trop quoi pour les autres).

Ceci permetrait d'écrire des requêtes en norme SQL standard quel que soit le type de SGBD.

---

Effectivement, je m'étais aussi fait cette réflexion plusieurs fois... Le plus simple à mon avis serait une surcharge de DbCommand.CreateParameter qui prend en paramètre le nom du paramètre.

En fait, il y a déjà un moyen de récupérer des infos sur le format des noms de paramètres, mais c'est pas super pratique (et surtout ça permet pas directement de générer un nom)

Code:

---

1 2	DataTable dataSourceInfo = connection.GetSchema("DataSourceInformation"); string parameterMarkerPattern = (string)dataSourceInfo.Rows[0]["ParameterMarkerPattern"];

---

Ca renvoie une regex qui correspond au pattern pour les paramètres, par exemple pour SQLite :

@[\p{Lo}\p{Lu}\p{Ll}\p{Lm}_@#][\p{Lo}\p{Lu}\p{Ll}\p{Lm}\p{Nd}\uff3f_@#\$]*(?=\s+|$)

Bref, c'est difficilement exploitable... :?

J'avoue n'avoir jamais approfondi le contenu de cette colonne ParameterMarkerPattern.

Merci pour l'info.

Elle est documentée où ?

Citation:

---

Envoyé par Bluedeep

Elle est documentée où ?

---

A ma connaissance, nulle part :aie: