J'ai un objet COM qui a comme membre un objet static  
Cet objet static initialise une connection ODBC vers une base Access.
Quand le programme appellant l'objet COM se décharge de la memoire, le destructeur de l'objet static est appelé.
Ca c'est normal ( et voulu )
Par contre quand le descructeur appel la fonction SQLDisconnect, windows ferme violemment le programme en indiquand "L'inscruxction xxxx a tenté d'utiliser l'adresse mémoire xxx qui ne peut être read..."
 
Par contre si je l'objet en question n'est plus static il n'y a plus de problème.
 
Sachant que tout ceci fait parti d'un programme particulièrement mal conçu et que la seul façon de débuger est de faire des fichiers de trace, si quelqu'un avait déja rencontré un problème similaire...

A l'intuition :  
 
(Si l'objet est en statique => plantage) et (l'objet pas statique => OK)
 
je me demande s'il n'y pas 2 tentatives d'appel de SQLDisconnect donc ma question est :  
 
Crées-tu 2 instances de ton objet COM ? (qui partagerait donc la même variable de classe)
 
2 solutions:
* variable pas statique
* variable remise à NULL après un appel conditionnel à SQLDisconnect si la variable n'est pas NULL.
 
 
 
 

Merci pour ton aide mais visiblement j'ai pas été très clair :
je resume, j'ai cela
 
class MonODBC
{
 MonODBC()
 ~MonODBC(){ ::SQLDisconnect(...);}
};
 
class MonCOM
{
 static MonODBC mODBC;  
};
 
Le problème arrive au moment ou le programme utilisant un objet de type MonCOM se décharge de la mémoire ( après la fin du main)
A ce momentle destructeur de mODBC est applelé ( normal ) et plantage lors de l'appel à SQLDisconnect.
 
SQLDisconnect ( fonction de lAPI ODBC qui prend un pointeur)  
n'est appelée q'une seule fois ( je trace les appels ) et de toute façon d'après la doc elle est capable de retourner une erreur en cas de pointeur invalide
 
mODBC étant un objet il ne peut pas être NULL.

 
Ah ok, c'est plus subtil...
Alors, autre hypothèse : Est-ce qu'il y a des threads dans l'histoire ?

Le problème se produit avec ou sans thread, c'est quoi l'idée ?

 
Ben je ne sais pas. Le SQLDisconnect prend un certain temps donc si l'objet est libéré paralellement dans un autre thread, l'instruction juste après le SQLDisconnect peut être indéfinie.

Bon ben j'ai trouvé une solution pour résoudre ce problème : virer Access   , car visiblement sous SQL Server ce problème ne se pose pas.
Donc la solution c'est MSDE ( un SQL Server light)