Discussion :

[clem_alain]

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 :

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

[Bluedeep]

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

- 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.

[clem_alain]

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 !

[Bluedeep]

Parfait. Ne pas oublier le bouton

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.

[tomlev]

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...

[clem_alain]

Parfait. Ne pas oublier le bouton



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 !"

[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