Erreur Execution 348 incompréhensible

Résolu
Calade - 26 mai 2014 à 14:16
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 - 27 mai 2014 à 15:57
Bonjour,

Je possède une DLL qui contient toutes les fonctions relatives à SQL et ADO que j'appelle dans mes applis selon le besoin.

Ces fonctions résident dans un .CLS dont la propriété instancing est GlobalMultiUse de manière à l'appeler sans instancier de classe (comme une fonction native VB en quelque sorte.

Tous mes foncions sont préfixées SQL_ de manière à ne pas interragir avec VB qui aurait une fonction du même nom.

Je précise que cette fonction n'a pas subi de modif depuis des lustres.
Suite à des modifs sur cette DLL (mais ailleurs) j'ai donc recompiler celle-ci AINSI que toutes mes autres DLL et OCX qui l'utilisent.

Or dans mon appli, à l'appel de cette fonction, j'obtiens une erreur d'exécution 438:
"L'objet ne gère pas cette propriété ou cette méthode"

Pour des test, j'ai donc ouvert le code de la DLL pour la suivre en pas à pas, or là, aucun problème.

J'ai essayé de recompiler la DLL, aucun changement.
J'ai vérifié mes paramètres de compilation, pas de changement.
J'ai changé le nom, toujours pareil.

J'avoue que là je suis à court d'idées.
Si quelqu'un avait une idée sur la direction où chercher, ce serait sympa.
Merci de votre aide.

PS: Je poste dans la catégorie VB6, car je ne pense que ce soit un problème SQL, ADO ou autre. J'avais déjà eu cette erreur aberrante pour une fonction qui n'a pas de propriété ou de méthode stricto sensu et en général, il suffisait de recompiler une seconde fois pour que cela soit résolu. Pais ici, non.

Merci d'avance

2 réponses

cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
27 mai 2014 à 15:00
Salut

Es-tu sûr que ton OCX compilé se trouve au bon endroit / que ton exécutable va utiliser le bon fichier ?
Vérifie s'il existe plusieurs fichiers portant le même nom que ton OCX sur ton disque.
Si tu en trouves plusieurs :
- Désenregistre ton OCX avec un "RegSvr32 -u mon.OCX"
- Supprime les fichiers inutiles
- Recompile ton OCX
Si tu déplaces ton fichier OCX, il faudra le ré-enregistrer avec un RegSvr32.
Normalement, ce genre de fichier devrait se trouver sous /Windows/System32/ (ou /SysWOW64 pour un 64 bits)
Tu peux aussi décider de la placer sur le même répertoire que ton application, mais je te le déconseille.
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
27 mai 2014 à 15:11
Il est aussi possible qu'il manque une référence, soit dans ton appli, soit dans l'une de tes DLL/OCX.

Perso, j'ai abandonné ce genre de structure et j'incorpore les fonctions à chaque projet - On est plus à l'époque où la taille des programmes peuvent poser problème.

Dernière 'idée' : affine tes gestions d'erreur : essaye de faire générer une MsgBox indiquant le nom du programme et le nom de la routine en défaut : tu sauras où ça coince.
0
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
27 mai 2014 à 15:57
Salut Jack et merci de ta réponse

J'avais déjà chercher des doublons en tout genre (fichier, fonction, etc...) mais, rien.

J'ai finalement résolu le problème en récrivant la fonction, ce qui a du avoir pour effet de changer sa signature (si tant est que ce genre de choses soit significatif en VB6).

Mais par contre, je me suis retapé de tout recompiler une cinquantaine de projets (y compris les exe finaux) sans savoir pourquoi.

Résolu pas pas compris donc !!!

Quant à ne plus utiliser des DLL/OCX et à tout inclure dans les projets, je ne suis pas trop client car les projets vont devenir énormes et cela n'aide pas le développement. L'IDE n'est pas des plus pratiques pour ça.
0
Rejoignez-nous