Discussion :

[JeanNoel53]

Bonjour

J'avance dans la migration de mon interface base de donnée et...
Je tombe sur un nouveau problème.

J'ai donc un statement qui a été exploité et dont je n'ai plus besoin.
Je veux le clore et utiliser un nouveau statement.
J'ai essayé plusieurs approches à partir de celle qui avait marché pour les trasactions et que j'indique ci-après

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
        if( m_pTSQLQuery != NULL)
           m_pTSQLQuery->Commit();
        else
           m_pTSQLQuery = TransactionFactory( m_pTSQLConnection, amRead, ilConsistency, lrWait, tfAutoCommit);
        m_pTSQLQuery->Start();

J'ai essayé d'utiliser la même construction pour le statement
et j'ai essayé plusieurs approches je donne ci-dessous la dernière
et je commenterai ensuite les résultats et l'erreur qui est toujours la même
Je terminerai par les pistes.
Le dernier code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
        // on démarre le statement
        if( bIsStatementAllocated == true)
        {
           delete m_pTSQLStatement;
           m_pTSQLStatement = new IBPP::Statement;
           *m_pTSQLStatement = StatementFactory( m_pTSQLConnection, m_pTSQLQuery);
        }
        else
        {
           m_pTSQLStatement = new IBPP::Statement;
           *m_pTSQLStatement = StatementFactory( m_pTSQLConnection, m_pTSQLQuery);
           bIsStatementAllocated = true;
        }

ensuite les manifestations de l'erreur:
J'ai démarré par tester m_pTSQLStatement != NULL et je suis tombé sur l'erreur
puis j'ai essayé de mettre un booleen pour le test et donc je suis tombé sur l'erreur au moment du Close(), et enfin je suis tombé sur l'erreur au moment du delete.
L'erreur est toujours la même dans IBPP.h un accès mémoire interdit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void clear()
		{
			if (mObject != 0) { mObject->Release(); mObject = 0; }
		}

Je penche comme voie de recherche à vérifier le premier StatementFactory qui ne semblait pas poser de problème, mais l'histoire montre que c'est souvent comme cela que ca se passe avec IBPP?
Qui peut m'orienter? ce serai cool

[JeanNoel53]

Bonjour
Je suis revenu à la première implémentation en ajoutant un Close après le StatementFactory

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
        if( m_pTSQLStatement != NULL)
        {
           m_pTSQLStatement->Close();
        }
        else
        {
           m_pTSQLStatement = StatementFactory( m_pTSQLConnection, m_pTSQLQuery);
           m_pTSQLStatement->Close();
           bIsStatementAllocated = true;
        }

le Close passe bien après le premier StatementFactory et donc il va falloir observer quand il est perverti

[JeanNoel53]

Le close s'opère bien jusqu'au get( int, char*) qui lit la dernière chaine retourné par la requète. Y a t'il un close d'office et dans ce cas pourquoi sans rien faire la requète suivante s'exécute t'elle mal, ou doit on refaire un StatementFactory à tous les coups après le dernier enregistrement, ou doit on ne rien faire ( mais ca bug au premier appel de PtrStatement)? A explorer

[JeanNoel53]

Le parcours au debuger du get( int, char*) ne donne la vue à aucune anomalie du Close(), et dans les deux cas d'appel du get successifs ( 1°get un get(int, int64) et le 2° est le get (int, char*)) le retour du get est false, signalant une donnée valide. Ces deux observations ne donnent donc pas d'explication à la dégradation du Close()
Je vais donc reprendre l'initialisation avec 1 StatementFactory et sans pour voir ce qui marche et ce qui ne marche pas

[JeanNoel53]

Visiblement il n'y a pas de PtrStatement valide après le Get( int, char*)
l'erreur en cas de nouveaux SegmentFactory est comme suit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Ptr& operator=(const Ptr& r)
		{
			// AddRef _before_ Release gives correct behaviour on self-assigns
			T* tmp = (r.intf() == 0 ? 0 : r->AddRef());// Take care of 0
			if (mObject != 0) mObject->Release();
			mObject = tmp; return *this;
		}

L'erreur apparait sur le release. Il faut donc examiner l'etat de l'objet avant et après la requète.

[JeanNoel53]

L'objet n'est pas modifié entre le début du get et la fin du get
Je n'ai pas d'autre idée. Qui en as

[JeanNoel53]

Eh oui, c'est un bête problême d'allocation mémoire mal gérée. Quand on passe une variable chaine de caractère au get (int, char*) il faut que la variable pointe sur un buffer. J'ai trouvé ce constat (non dit?) en inversant les deux appels de get, et le défaut était masqué par les initialisations du premier get qui masquait la non allocation de mémoire
Plus de problème