Erreur -804 [Résolu]

[jibe74]

Bonjour,

J'ai un problème dont je ne parviens pas à trouver l'origine. J'ai fait la procédure stockée suivante :

Code :

1
2
3
4
5
6
7
8
BEGIN
     SELECT SUM(LIGQTE * LIGCAL), SUM(LIGCOL), SUM(LIGPUV * LIGQTE * LIGCAL)
     FROM LIGNE
     WHERE CDENNN = :NUM_CDE
     GROUP BY CDENNN
     INTO :TOT_POIDS, :TOT_COLIS, :TOT_PRIX;
     SUSPEND;
END

Testée avec IBOConsole et IBEasy, elle fonctionne très bien. Mais appelée par un programme en C++Builder, elle me renvoie l'erreur suivante :

Code :

1
2
3
Dynamic SQL error
SQL error code = -804
SQLDA missing OR incorrect version, OR incorrect number/type of VARIABLES

Le code d'appel est on ne peut plus simple :

Code :

1
2
3
SPTotCom->Params->Items[0]->AsInteger=TCom->FieldByName("CDENNN")->AsInteger;
SPTotCom->Prepare();
SPTotCom->ExecProc();

Deux précisions utiles :

• J'utilise les composants SQLDirect
• d'autres procédures stockées (utilisées dans un cadre plus complexe) appelées par le même programme fonctionnent très bien

Ne voyant à priori pas bien quel pourrait être ce problème SQLDA (sûrement pas une version incorrecte, puisque les appels d'autres procédures fonctionnent bien !) et ayant vérifié et re-vérifié mon nombre et types de variables (c'est vite fait, vu le nombre ), j'ai commencé à chercher plus de précisions sur cette erreur -804. Et là, je trouve plusieurs choses à propos de :

Dynamic SQL error
SQL error code = -804
Function unknown

Et encore ceci :

This error is often the result of mismatched Firebird/InterBase client and
servers. Make sure client and server versions of gds32.dll are the same.



Je crois deviner que le code -804 est utilisé pour plusieurs types d'erreur et que, finalement, il doit y avoir quelque chose qui m'a échappé au niveau du passage des variables et de SQLDA, mais je vois de moins en moins comment résoudre le problème... Ou alors, la solution est si évidente qu'elle m'aveugle ?

Quelqu'un peut éclairer ma lanterne ?

[jean-jacques varvenne]

avant d'aller plus loin, il faudrait régler le problème

Code :

1
2
3
 
This error IS often the result of mismatched Firebird/InterBase client AND
servers. Make sure client AND server versions of gds32.dll are the same.

car d'après ce message, il est fort probable et même certain qu'il y a une incompatibilité avec la dll qui sert de communication entre ton pc et le serveur.

un truc à vérifier est de cliquer droit sur "gds32.dll" et de contrôler que sa version soit directement compatible avec le serveur interbase ou firebird.

pour cela il faudra voir auprès de l'administrateur du serveur si cette machine fait fonctionner interbase ou firebird et de quelle version il s'agit.

avec ces infos, il sera plus facile de sélectionner la bonne "gds32.dll".

a défaut et le plus simple et de recopier la "gds32.dll" du serveur sur ta machine, soit dans le dossier "system32" soit dans le même dossier que ton application.

en principe cela devrait régler le problème de communication entre ton application et le serveur
jj

[jibe74]

Bonjour,

Merci pour le tuyau

Mais c'est une fausse piste ! En effet, je teste mon programme en local (il est destiné ensuite à aller chercher les données sur un serveur Linux). De plus, tout le reste du programme, y compris des appels de procédures stockées, fonctionne très bien...

Je n'ai recopié ce message que pour montrer les différentes explications que j'ai trouvées concernant cette erreur -804, et qui me laissent un peu sceptque. Comme il ne peut s'agir ni d'un problème de fonction inconnue ni d'un problème de dll incompatible entre serveur et client, je me demande si c'est bien un problème de paramètres comme semble l'indiquer le message. Si c'est bien ça, c'est que quelque chose m'échappe, parce que le nombre et le type de paramètres est correct...

[jean-jacques varvenne]

ce qu'il me faudrait c'est la déclaration de votre procédure stockée, qui n'apparait pas dans le code que vous montrez. surtout les paramètres dans la clause RETURNS.

parce que l'idée suivante et qu'il y a un paramètre d'entré ou de sortie qui n'est pas adapté pour le c++

ce cas arrive par exemple lorsque le type produit et un smallint et le type attendu un integer! très con, mais cela passe la plus part du temp inaperçu, car les les programmes de visualisations s'adaptent automatiquement au type alors que votre programme non!

donc si vous n'avez pas encore trouvez, pensez à contrôler soigneusement les types des données envoyées et reçues!
jj

[jibe74]

Bonjour,

Merci de vous pencher sur mon problème !

Voici donc la procédure complète :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
SET TERM ^ ;
 
/* Stored procedures */
 
CREATE PROCEDURE "PS_TOTAL_CDE" 
(
  "NUM_CDE" INTEGER
)
RETURNS
(
  "TOT_POIDS" DECIMAL(9, 3),
  "TOT_COLIS" INTEGER,
  "TOT_PRIX" DECIMAL(8, 2)
)
AS
BEGIN
     SELECT SUM(LIGQTE * LIGCAL), SUM(LIGCOL), SUM(LIGPUV * LIGQTE * LIGCAL)
     FROM LIGNE
     WHERE CDENNN = :NUM_CDE
     GROUP BY CDENNN
     INTO :TOT_POIDS, :TOT_COLIS, :TOT_PRIX;
     SUSPEND;
END
 ^
 
SET TERM ; ^

La récupération des données manquait aussi, voici donc le traitement complet de la procédure par le programme C++ :

Code :

1
2
3
4
5
6
SPTotCom->Params->Items[0]->AsInteger=TCom->FieldByName("CDENNN")->AsInteger;
SPTotCom->Prepare();
SPTotCom->ExecProc();
RidBComFrm->Edit3->Text=FloatToStr(SPTotCom->Params->Items[1]->AsFloat);
RidBComFrm->Edit2->Text=FloatToStr(SPTotCom->Params->Items[2]->AsInteger);
RidBComFrm->Edit1->Text=FloatToStr(SPTotCom->Params->Items[3]->AsFloat);

Je précise que l'erreur se produit lors de l'appel de la procédure ( SPTotCom->ExecProc(); ). Raison pour laquelle j'avais tendance à écarter l'hypothèse d'un problème de passage de variables (surtout des variables en sortie !). Mais comme par ailleurs la procédure fonctionne bien lancée dans IBOConsole...

[jean-jacques varvenne]

l'erreur est subtile, essayez de supprimer le "suspend" de la procédure, car "suspend" indique que la procédure est en mesure de retourner des infos "ligne à ligne" dans un select, par exemple, il est possible d'appeler votre procédure par une commande sql:

Code :

 SELECT * FROM PS_TOTAL_CDE( 75000 );

alors que vous tentez de l'exécuter en tant que procédure simple.

donc à votre choix:

1) vous supprimez le "suspend;" de la procédure, mais dans ce cas, vous ne pourrez plus effectuer la commande "select" mais vous conservez le code de l'application, pour autant que c'est comme cela qu'il faut appeler une procédure à partir du cpp.

2) vous changez le "execproc" par un "open" dans le programme et vous considérez alors que vôtre procédure et une "table" et vous implémentez le code en conséquence, dans ce cas laissez le "suspend" dans la procédure et implémentez dans le code la commande "select ..." comme pour lire une table "ordinaire" et faite un "fetch" pour récupérer le resultat.

en principe cela devrait fonctionnez, notez que je n'est pas fait attention à d'autres erreurs éventuelles.

A notez que la plus parts des programmes de visualisations utilise directement un "select" au lieu d'un execproc, c'est pour cela que cela fonctionne avec ces programmes et pas le votre.

[jibe74]

Bonjour,

Merci de vous pencher sur mon problème. Malheureusement, j'ai encore des difficultés à le résoudre...

J'ai tenté de supprimer le suspend. Dans ce cas, la procédure ne retourne rien dans les paramètres de sortie lorsque je la teste avec IBOConsole, ce qui parait logique, et ne renvoie pas d'erreur. Mais le programme en C++, lui, me renvoie toujours le même message...

J'ai ensuite tenté un open sur mon composant SDStroredProc. Mais à ce moment-là, j'obtiens un message "error creating cursor handle" (au passage, je me demande si ce n'est pas parce que le composant attend plusieurs lignes, sinon pourquoi un curseur ?).

En cherchant un peu comment je pourrais faire, par exemple en utilisant un TQuerry pour appeler ma procédure par un ordre SQL - Ce qui me chagrine quand même un peu, il me semblait préférable de l'appeler directement, mais bon, l'important est le résultat ! - je suis tombé sur ce post où un suspend est bien utilisé conjointement avec un ExecProc... Du coup, je m'interroge à nouveau sur ce que j'ai pu ne pas comprendre...

[Barbibulle]

Votre procédure devrait fonctionner parfaitement (avec ou sans suspend) si vous utilisez un ExecProc.

Si vous utilisez un composant Query il faut evidemment mettre le SUSPEND.

Mais à mon avis si vous êtes certain d'avoir la version de la DLL cliente correspondant à la version du serveur (Donc que vous avez utilisez le même programme d'installation pour interbase serveur et interbase client) c'est que votre probleme vient de SQLDirect tout simplement.

Avez vous la dernière version de ce produit ?

[jibe74]

Bonjour,

Merci pour la réponse. J'étais effectivement en retard de version SQLDirect. J'ai réinstallé la dernière, mais hélas cela n'a pas résolu le problème : j'obtiens toujours le même message d'erreur. Pour être vraiment sûr, j'ai désinstallé et réinstallé SQLDirect et Firebird, mais sans plus de succès...

Je reprécise les différents éléments utiles :
- OS de développement : Windows98 SE (par habitude et par goût...)
- SGBD : Firebird 1.51 superserveur local
- IDE de développement : C++Builder 5 Professional
- Composants d'accès au SGBD : SQLDirect version 4.1
- OS de destination : clients Windows XP Pro sur serveur Linux

Serais-je donc en présence d'un bug de SQLDirect ?

[Barbibulle]

Envoyé par jibe74

Serais-je donc en présence d'un bug de SQLDirect ?

C'est possible, Pour en être certain il faudrait par exemple que vous essayez d'exécuter cette PS avec les IBX par exemple (qui utilisent eux aussi un accès natif à Firebird via la DLL GDS32.DLL).

Créez un projet de test à part posez les composants IBDataBase (double cliquez dessus pour configurer la connexion) un IBTransaction liez le au composant IBDatabase et le IBDatabase à IBTransaction et un IBStoredProc que vous liez à l'IBDatabase et à votre PS.

Ca vous prendra 5 / 10 Minutes au plus.

[jibe74]

Bonjour,

Envoyé par Barbibulle

Ca vous prendra 5 / 10 Minutes au plus.

Certes, le test est facile et rapide... A condition d'avoir les composants nécessaires !

Je ne suis pas sûr que ce soit le cas avec la version Pro de CBB... Je regarde si je n'ai pas les composants IB Local et s'ils conviennent...

[Barbibulle]

Les IBX sont fournis avec Delphi et BC++ à partir de la version PRO.

Palette Interbase.

[jibe74]

Re-bonjour,

Me revoilà, après avoir pris le temps de faire quelques essais.

Effectivement, nouvel utilisateur de Firebird, j'avais essayé sans succès de me servir des composants IBX, puis m'étais dit qu'ils devaient être réservés à l'utilisation avec IBLocal et les avais viré de ma palette bien garnie !

Apparemment, j'avais dû mal faire quelque chose, car après les avoir réinstallés et utilisés pour le test que vous me préconisez, je vois qu'ils fonctionnent très bien avec Firebird .

Donc, je confirme : il y a apparemment bien un bug dans SQLDirect, parce que le test avec les IBX fonctionne nickel, alors qu'avec SQLDirect j'ai toujours le problème, que j'utilise Params->Items[x] ou ParamsByName().

Me reste maintenant à trouver un moyen de contourner le problème. Puisqu'apparemment ils fonctionnent bien, je me demande si je ne devrais pas utiliser les IBX plutôt que SQLDirect... A moins que quelqu'un ait un meilleur conseil ?

En tous cas, merci !

[Barbibulle]

Vous avez la solution d'utiliser un query.
Et de reporter le BUG à SQLDirect en espérant un correctif.

A moins que vous en soyez au début de votre développement dans ce cas il peut etre interressant de refaire le point sur vos besoins de connectivité.

[jibe74]

Merci beaucoup pour l'aide !

Oui, quoi qu'il en soit, je vais reporter ce bug à SQLDirect. Mais je crains que le correctif tarde un peu à arriver... Je pense que les développeurs de SQLDirect ont déjà bien du pain sur la planche !

Bien que n'en étant pas au début de mon développement, je pense que la migration ne devrait pas être trop longue ni difficile. Je vais étudier la question... J'avais opté pour SQLDirect en pensant que je n'avais rien d'inclus d'origine dans CBB me permettant d'attaquer une base firebird, mais du coup, avec la découverte du bon fonctionnement des IBX et de ce bug dans SQLDirect, je me dis que ce serait peut-être mieux de repartir sur les IBX...

[Barbibulle]

Je pensais que vous aviez choisi SQLDirect pour pouvoir "attaquer" éventuellement d'autres SGBD sans devoir trop changer votre code.

Si ce n'est pas le cas mais que vous cherchez un accès natif alors les IBX sont plus adaptés.

Cependant il faut savoir que Borland ne maintiendra pas une compatibilité des IBX avec Firebird. Actuellement ils fonctionnent parfaitement mais dans l'avenir il y aura certainement des différences qui feront qu'on ne pourra pas exploiter toutes les nouveautées des prochaines versions de Firebird.

Donc un jour ou l'autre il faudra que vous fassiez le choix entre :
1- Ne pas faire évoluer vos serveur Firebird (concerver la version 1.5)
ou
2- Ne plus utiliser les IBX mais des composants qui sont développés pour fonctionner avec Firebird.

Il existe par exemple les FIBPlus http://www.consist.it/devrace.htm qui apportent déjà pas mal d'améliorations par rapport aux IBX et qui normalement devraient rester compatible avec les évolutions future de Firebird. Ils sont dispo pour Delphi / BC++ et aussi pour Kylix.
Il en existe d'autre mais pour le moment si je devais migrez mes applis IBX vers quelque chose je pense que ca serait vers ces FIB+. Notamment parqu'ils proposent des composants très similaires aux IBX facilitant ainsi la migration.

[jibe74]

Bonjour,

Merci beaucoup pour ces précieux renseignements et conseils !

C'est vrai que, d'après le site, les FIBPlus ont l'air vraiment super. Je vais télécharger la version de démo pour voir ça de plus près...