[Résolu] Fermeture inopiné application Delphi

Fermeture inopiné application Delphi [Résolu] - Delphi/Pascal - Programmation

Marsh Posté le 13-10-2009 à 13:39:53    

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


Message édité par stark2099 le 17-11-2009 à 16:36:19

---------------
Stark
Reply

Marsh Posté le 13-10-2009 à 13:39:53   

Reply

Marsh Posté le 15-10-2009 à 09:17:32    

Est-ce que ça viendrait pas de la donnée ?

Reply

Marsh Posté le 19-10-2009 à 12:50:02    

Bonjour,
Non, ce ne sont pas les données. Elles sont valides et plus ou moins identiques.
Par contre, 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 …

Reply

Marsh Posté le 17-11-2009 à 16:34:19    

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

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed