RaiseError (PERL, DBI) équivalent pour l’API C unixODBC?

J’ai un problème pour exécuter certaines procédures / fonctions stockées dans INFORMIX DB. J’ai essayé avec différents clients et ils étaient tous identiques – personne ne détecte d’erreurs lors de l’exécution au lieu de cela – renvoie des réponses vides. Et ça ne marche pas pour moi.

Enfin, j’ai découvert que PERL DBI avait la possibilité de définir RaiseError , par exemple:

 { PrintError => 0, RaiseError => 1 } 

Et cela fonctionne parfaitement. Mais existe-t-il un tel équivalent (je n’ai malheureusement rien trouvé) pour la lib unixODBC C API ?


De plus: j’ai essayé la même requête avec isql et c’est pareil! Aucune erreur, juste un résultat vide: \ Peut-être que ce pourrait être une option, qui devrait être configurée (dans odbc.ini , je suppose ..)?


EDIT : Ok, voici quelques détails supplémentaires:
Version: unixODBC 2.3.0

 CREATE FUNCTION "test".NOK_func_k() RETURNING LVARCHAR(1000); set debug file to '/home/directory_does_not_exists/unknown.log'; trace off; trace on; trace off; return 'result is set here'; END FUNCTION; CREATE PROCEDURE "test".NOK_proc_k(pDummy SMALLINT) set debug file to '/home/directory_does_not_exists/unknown.log'; trace off; trace on; LET pDummy = 2; trace off; END PROCEDURE; 

Et les résultats des ODBC C API isql et ODBC C API sont les mêmes. Voici plus d’informations sur l’ C API :

 Executing: execute procedure NOK_proc_k(1) retcode = SQL_ERROR SQL_SUCCEEDED( retcode ) = 0 -------------------------------------------------- Executing: execute function NOK_func_k() retcode = SQL_SUCCESS SQL_SUCCEEDED( retcode ) = 1 -------------------------------------------------- -------------------------------------------------- Executing: execute function NOK_proc_k(1) retcode = SQL_ERROR SQL_SUCCEEDED( retcode ) = 0 -------------------------------------------------- Executing: execute procedure NOK_func_k() retcode = SQL_SUCCESS SQL_SUCCEEDED( retcode ) = 1 -------------------------------------------------- -------------------------------------------------- Executing: call NOK_proc_k(1) retcode = SQL_ERROR SQL_SUCCEEDED( retcode ) = 0 -------------------------------------------------- Executing: call NOK_func_k() retcode = SQL_SUCCESS SQL_SUCCEEDED( retcode ) = 1 

Tous les appels à SQLMoreResults renvoient SQL_NO_DATA , tous les SQLFetch renvoient SQL_ERROR .

Résumé – tous les appels aux mauvaises procédures sont corrects – une erreur est renvoyée. Mais si cette erreur est dans la fonction stockée – aucune erreur n’est détectée; au lieu de cela, la chaîne EMPTY est renvoyée. Outch!

SQL_SUCCESS_WITH_INFO n’est renvoyé nulle part. Et c’est comme ça pour beaucoup d’autres erreurs (pas toutes, bien sûr, ce n’est qu’un exemple ici)


Et encore plus! Procédure ou fonction comme:

 CREATE PROCEDURE "test".nok_proc_k_2() RETURNING LVARCHAR(1000); DEFINE vNotDefined VARCHAR(10); LET vNotDefined = current; END PROCEDURE; 

Ne renvoie aucune erreur, alors qu’un studio Aqua DB renvoie

 Converted value does not fit into the allotted space 

RÉPONSE:

J’accepterai la réponse de bohica, car elle est correcte et répond correctement à la partie concernant PERL DBI . En outre, il m’a vraiment aidé (le coup avec strace ).

En tout cas, la vraie solution n’est pas là. Je l’ai posté dans la question correspondante, qui est plus spécifique et isolée du cas particulier: la même erreur est détectée dans la procédure stockée **, mais pas dans la fonction stockée **

Tout ce que RaiseError dans Perl dit, c’est quand un DBD, comme DBD :: ODBC, voit une erreur, DBI appelle tous les gestionnaires d’erreur enregistrés et appelle die avec cette erreur (selon ce que le gestionnaire d’erreur a renvoyé). Il appartient toujours au DBD de signaler l’erreur à DBI via la méthode set_err.

Je suppose que votre Perl utilisait DBD :: ODBC. DBD :: ODBC va simplement vérifier l’état de retour de chaque API ODBC qu’il appelle et s’il s’agit de SQL_SUCCESS_WITH_INFO, il appelle DBIs set_err en lui indiquant qu’il s’agit d’un avertissement et que! SQL_SUCCEEDED appelle alors set_err en signalant une erreur (il existe quelques exceptions telles que SQL_NO_DATA qui n’est pas toujours une erreur).

Si vous dites que Perl meurt avec l’erreur que vous attendez mais que votre code C ne le fait pas, vous ne devez pas vérifier le retour d’API ODBC ou peut-être (puisque vous mentionnez des procédures) vous ne vous assurez pas d’appeler SQLMoreResults dans une boucle après SQLExecute le le SQL pour appeler la procédure. N’oubliez pas que certaines bases de données exécutent chaque insertion / sélection / mise à jour dans une procédure une par une. Dans ODBC, vous devez appeler SQLMoreResults pour les parcourir. Si vous ne le faites pas, votre procédure n’est pas terminée et par conséquent vous n’avez peut-être pas atteint l’erreur.