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

[Bluedeep]

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.

[tomlev]

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 C# :

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

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

[Bluedeep]

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

Merci pour l'info.

Elle est documentée où ?

[tomlev]

Elle est documentée où ?

A ma connaissance, nulle part