[ASE-12.0] exécuter procédures stockées avec ODBC [Résolu]

[msomso]

Bonjour
Nous devons exécuter des procédures stockées sybases via ODBC à partir de PYTHON.
Nous arrivons à nous connecter et exécuter les ordres insert, select.
Par contre lancement d'une procédure stockée avec un ordre insert ne s'effectue pas: pas d'exception/erreur mais rien dans la base alors qu'un commit ODBC est fait. Par ailleurs, la même procédure fonctionne bien sous isql.

Mais de votre aide
msomso

[mpeppler]

Note: Je ne my connais pas trop en ODBC, ni en Python...

Est-ce que le code client "consomme" correctement tous les résultats renvoyés par le serveur ?
Lorsqu'on exécute une proc stockées il y a en général plusieur set de résultats (result sets) qui sont renvoyés, même si il n'y a pas de SELECT dans la proc. Il faut donc que le client cherche tous ces résultats.

En pseudo code C (avec Client Library) cela donne qqch comme ceci:

Code :

1
2
3
4
5
6
7
8
9
 
ct_command(... ma requête ...);
ct_send(..);
while(ct_results(&result_type) == CS_SUCCEED) {
    IF(result_type IS fetchable) -- CS_ROW_RESULT, CS_STATUS_RESULT, etc.
        while(ct_fetch()...)
            ... et ON fait qqch avec les données reçues ...
        }
}

ODBC doit évidemment être capable de faire la même chose (MS-SQL utilise un protocol quasi identique), et j'imagine que Python aussi.

Maintenant c'est évidemment possible (voir probable!) que ce qui est décrit ci-dessus n'a rien à voir avec ton probléme...

Michael

[msomso]

Bonjour
Notre cas concerne une procédure d'insertion. Il s'agît d'un insert basic à partir des parametres d'entrée. Seule la clé primaire est calculée par la procédure. Lors de l'exécution via ODBC, l'ordre est ignoré sans aucun message d'erreur. L'enregistrement n'est pas inséré et de plus la valeur PK retournée par la proc est NULL, comme si la procédure ne s'était pas exécutée.

Ne faut-il pas d'autorisation (grant) spécifique pour appeler les procédures via ODBC ?

Merci d'avance pour toute suggestion.
msomso

[mpeppler]

Si cette proc peut être exécutée via isql avec le même user de connexion que celui utilisé via ODBC alors ce n'est en tous les cas pas un problème de grant.

Un autre problème possible: est-ce que la connexion ODBC est créée en mode "chained transaction" (cad Auto Commit OFF) ?
Si c'est le cas il faut peut être exécuter sp_procxmode:

Code :

1
2
3
 
sp_procxmode <nom_de_la_proc>, anymode
go

[msomso]

Pour la connection: on utilise :

pyodbc.connect ("DSN=%s;DATABASE=%s;UID=%s;PWD=%s"%(<dsn>,<base>,<log>, <pwd>)

On a fait aussi un commit explicit ODBC.
Si c'était un problème de commit, on devrait alors au moins recupérer l'identifiant calculé dans la proc, or il est non renséigné.

Je comprends qu'il soit difficile de trouver de l'aide sur ce point particulier.
En attendant, nous avons contacté le support Sybase. Etant limité dans le temps, nous sommes en train de remplacer les appels à nos procédures par du code Python avec des appels sql simples via ODBC.

Une solution serait quand même appréciée.
Ce pourquoi, je propose, si possible de ne pas fermer tout de suite cette discussion.

Nos Versions:
-- poste client:
Python -> 2.5 (avec la librairie pyodbc)
ODBC -> 5.00.00.87
OS -> Windows 2000 Terminal
-- serveur Sybase
OS de serveur ASE -> Sun 5.8 32 bits
ASE -> 12.0.0.3

Merci
mso

[mpeppler]

Est-ce que tu as essayé de passer le sp_procxmode sur ta procédure ?

Michael

[msomso]

Oui, je l'ai fait mais aucun changement pour ODBC.
Merci
mso

[kagemaru]

peux-tu poster le bout de code où tu appelles la proc ? (je suis une bille en python également mais ça me semble bizarre ...)

[fadace]

Afin de s'assurer qu'il ne s'agit que d'un problème de configuration, essayez de lancer votre procédure stockée via MS-Access

Requêtes -> Nouveau -> Mode Création
Requête -> Spécifique SQL -> SQL Direct

Qu'est-ce que cela donne ?
Quelles sont les spécificités de la librairie ODBC utilisée ? Quel en est l'éditeur ? Sybase ? Intersolv ? Microsoft ?

[msomso]

Bonjour
Selon le support Sybase (platforme de test legérement différente de notre), le principe fonctionne. Nous avons pourtant utilisé les mêmes appels qu'eux.
On pense que l'environnment de dev de notre client est en cause de ce problème. Nos procédures ont été transcrites en appels sql à partir de Python.

Vuloir à tout prix élucider ce problème,nous aurait prit trop de temps.

Je ferme la discussion, et merci bien de votre interêt.
msomso