Fermeture inopinée application Delphi

Bonjour,
J'ai récement migré le développement d'une application de Delphi 6 vers Delphi 2006.
Je rencontre un problème avec l'application : elle crash et se ferme sans afficher de message d'erreur. Ceci de façon assez alléatoire.
Après quelques tests j'ai obtenu en mode debug le message : " Debugger fault notification
Projet c:\toto.exe faulted with message:'access violation at 0x4da2ef6d: read of address 0xbfc8e3e8'. Process stopped. Use Step or Run to continue. "

J'obtiens ce message lorsque j'essaie de faire une mise à jour de données avec l'instruction Query.ApplyUpdates . Pas de problème sur les lectures.
L'erreur est aléatoire : elle se produit à différent endroit dans l'application mais pas de façon systématique.

Les données sont hébergés sur un serveur MS SQL Server 2005. Les accès aux données se via une entrée DSN mapé par le BDE.
J'utilise pour me connecter des TDatabase. Des TwwQuery (composant héritant de TQuery) pour la manipulation des données. Et des TUpdateSQL liés aux
TwwQuery pour les mises à jour. L'application est lancé sur un Windows XP (SP2 ou SP3)

La configuration BDE est la suivante :

- Drivers --> ODBC --> SQL Server :
Version : 5.0
TYPE : SERVER
DLL : IDODBC01.DLL
DLL32 : IDODBC32.DLL
ODBC DRIVER : SQL Server
BATCH COUNT : 200
BLOG SIZE : 64
BLOBS TO CACHE : 128
ENABLE BCD : FALSE
ENABLE SCHEMA CACHE : FALSE
MAX ROWS : -1
OPEN MODE : READ/WRITE
ROWSET SIZE : 20
SCHEMA CACHE SIZE : 8
SQLPASSTHRU MODE : SHARED AUTOCOMMIT

- System --> INIT :
AUTO ODBC : FALSE
DEFAULT DRIVER : PARADOX
LANGDRIVER : 'ascii'ANSI
LOCAL SHARE : FALSE
LOW MEMORY USAGE LIMIT : 32
MAXBUFSIZE : 2048
MAXFILEHANDLES : 192
MEMSIZE : 32
MINBUFSIZE : 128
MTS POOLING : FALSE
SHAREDMEMLOCATION :
SHAREDMEMSIZE : 4096
SQLQRYMODE :
SYSFLAGS : 0
VERSION : 4.0

J'ai rencontré le problème il y a 2 semaines et depuis je sèche.
J'ai testé plusieurs configuration de BDE, vérifier que j'avais bien la dernière du MDAC, mis à jour le MS SQL Native Client

Si quelqu'un peut m'aider ...

Merci d'avance.

Stark.2099

Salut;
c'est un message de débogueur, vous pouvez l'enlever dans les options de déboguer (Juste pour que vous testiez l'application)
essayer on cliquant sur le menu Outils==> Options de déboguer ===>Cliquer sur l'onglet Exception du langage===> puis décocher l'option "Arrêter sur exception Delphi"
Cordialement
ghilo

J'ai le message même en désactivant les notifications d'exception Delphi. Et mon application plante toujours. :?

Stark.2099

Citation:

Envoyé par ghilo

Salut;
c'est un message de débogueur, vous pouvez l'enlever dans les options de déboguer (Juste pour que vous testiez l'application)
essayer on cliquant sur le menu Outils==> Options de déboguer ===>Cliquer sur l'onglet Exception du langage===> puis décocher l'option "Arrêter sur exception Delphi"
Cordialement
ghilo

Alors attend l'avis des experts :mouarf:
Ghilo

Suite à un conseil qui m'a été donné sur un forum, suis allé voir ce que contenait l'adresse mémoire 0x4da2ef6d. Puis comme je n'arrivais pas comprendre l'assembleur j'ai fait du pas à pas (F7) jusque dans les fichiers sources de bibliothèques de Delphi. Résultat :
le plantage a lieu non sur une mise à jour de query mais sur une fermeture (Query.Active := False)

Dans le processus de fermeture, la fonction BdeCallBack du fichier DBTables est appelée et plante. C'est une fonction interne au BDE. Je ne sais pas du tout pourquoi elle plante sur cette fermeture alors que les précédentes se sont déroulées sans erreurs et que les valeurs de paramètres n’ont globalement pas changées …

STARK.2099

Bonjour,
En fait mon problème est un Stack Overflow lors des traitements liés à la mise à jour de Querys.

Lorsque l'on effectue un Query.ApplyUpdate(), le dataSet met a jour une ligne puis parcours la collection de champs de celle-ci.

Pour chaque valeur de la collection sont effectuées un certain nombre d'empilements et de dépilements.

Les mêmes opérations d'empilements et de dépilements sont faites lors d'activation/desactivation de Query.

Dans mon cas, le mixe des 2 (Query.ApplyUpdate + plusieurs d'activation/desactivation de Query dans Query.BeforeUpdates() ou un Query.calculfield() ) provoque le Stack Overflow.

J'allège mes traitements et optimises mes appels de Query, cela semble régler le problème.

Stark