Probleme violation de la mémoire

Bonjour,
j'obtiens cette erreur lorsque j'éxécute un petit programme :
"L'exception System.AccessViolationException n'a pas été gérée
Tentative de lecture ou d'écriture de mémoire protégée. Cela indique souvent qu'une autre mémoire est endommagée."
Détail: System.AccessViolationException
"
Le programme lit une base de donnée et cherche le correspondant dans une autre base de donnée. L'erreur n'arrive jamais au meme endroit ou au meme enregistrement. Parcontre elle arrive toujours lorsque par une fonction (contenu dans un dll qui est en référence) attribue une valeur a une variable. C'est un peu weird ...

Merci de votre aide

Ya fort à parier que ça vienne de la DLL, genre mémoire mal allouée, libération de mémoire anticipée, tentative d'acces à une zone mémoire qui a déjà été effacée mais dont le pointeur n'a pas été mis à NULL, ce genre de choses codées par des gruic gruiiic :)


Gérôme GUILLEMIN
Auteur du langage FBSL

Moi je parirais plus pour un problème d'appel à la dll.

Je ne pense pas que ce soit la dll qui est en cause, mais plutot la façon dont tu t'en sert.



---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

c'est que l'appel de la fonction (qui est storé dans la dll ) est dans une boucle qui va tournée autant fois qu'il ya des donnée dans la bd (genre 5 000 fois). Mais elle va donnée l'erreur des fois Exemple au 3000ieme enregistement sur le champ B et d'autre fois au 2800ieme sur un autre champ. Les fois d'avant elle fonctionne bien... Il semble pas avoir de relation avec le champ ou la donnée lu. Sa me semble comme si y aurais pas de mémoire disponible additionnelle. Pourtant j'ai 2gig de mémoire.

Tu es en VB2005, comment déclare-tu les fonctions de ta dll ??? Il se peut que le type de variable que tu lui passe ne corresponde pas à ce qu'elle attent.

Autre point, est-ce que tes variables sont correctement instanciées avant de les passer à la dll. Ex, si tu lui passe une chaine de caractère qu'elle doit remplir, cette chaine doit au préalable etre correctement remplie avec suffisament de caractères pour qu'elle existe en mémoire.

Le mieux est que tu mette le bout de code qui pose problème.


---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

Voila ma déclaration de la fonction de la dll

PublicDeclareFunction TDBFieldGetValueAsString Lib"F:\filedll\tdbaccess.dll" (ByVal DBIndex AsInteger, ByVal TableName AsString, ByVal FieldName AsString, ByVal RecNo AsInteger, ByRef OutBuffer AsString) AsBoolean

Variable déclarer dans ma procedure

Dim

PLAYERFIRST As String = ""
Dim PLAYERCITY AsString = ""
Dim PLAYERLAST AsString = ""
Dim PLAYERindx AsInteger = 0

'PARTIE  DE CODE

'HandleEXH est mon fichier ouvert de base de donnée.
For I = 0 To (TABLEINFO.RecordCount - 1)

   TDBFieldGetValueAsString(HandleEXH,

"SPBT", "FNME", I, PLAYERFIRST)
    TDBFieldGetValueAsString(HandleEXH, "SPBT", "LNME", I, PLAYERLAST)
   TDBFieldGetValueAsString(HandleEXH, "SPBT", "CITY", I, PLAYERCITY)
   TDBFieldGetValueAsString(HandleEXH, "SPBT", "INDX", I, PLAYERindx) L'erreur peut arriver a n'importe quelle ligne des fonction TDBfield.. c'est aléatoire jusqu'a maintenant. Et sur n'importe quel enregistrement(la valeur de I est différence a chaque erreur.) La fonction TDBfield lit une valeur dans la table SPBT, sur le champ FNME etc. à l'enregistrement I et la place dans la variable au bout ex: PLAYERFIRST.

Voilà je ne sais pas si vous avez assez d'info pour m'aider
Merci!!!!!.

Merci, Merci 
ca fonctionne tres bien lorsque j'initialise la variable a chaque tour. C'est un détail que j'avais vue.

J'ai perdue une semaine à fouiller et changer mes procedures pour que tu me fasse découvrir qu'il fallait initialiser la variable a chaque tour de la routine pour la dll peuvent y inclure l'info.

Mais est ce type a visual studio 2005 ou si je l'avais fais en Vb6 ca aurait fonctionner sans l'initialiser a chaque tour ?

Ca aurait été exactement pareil en VB6, c'est d'ailleurs comme ça que l'on fait lorsque l'on utilise les fonctions de l'api Windows.

Ceci est dû à la spécificité des variables de type string. Pour la pluspart des variables simples, ta variable dans le code représente une zone mémoire ou est réellement stocké la valeur de ta variable. Dans le cas des strings, la variable dans le code représente en mémoire, non pas une zone ou est stocké la chaine de caractère, mais une zone ou est stocké l'adresse d'une autre zone mémoire qui elle contiendra réellement la chaine de caractère. Dû au fonctionnement du traitement des string, cette derbière zone change en permanence de place, il est donc plus facile de stocké dans une variable fixe l'adresse d'une zone mémoire plutot que de modifier en permanance la position de cette variable et ainsi planter le programme qui aurait du mal à retrouver cette variable.

Pour ce qui est des dll, comme je te disais, généralement elles ne sont pas capable de créer de zone mémoire ou stockées les chaines. Elles ne font que copier les caractères dans une zone qui leurs a été indiqué. Mais si cette zone n'existe pas (string de longueur nulle par exemple) ou qu'elle est trop courte, la dll n'est pas capable de le savoir et va allègrement déborder sur les données qui suivent en les détruisant. Ces données étant corrompues, cela provoque soit un plantage, soit des erreurs, soit des violation d'accès.

C'est pour cela que lorsque tu passe une chaine de caractère à une dll de ce type qui doit y écrire dedant, cette chaine doit avoir au préalable été remplie pour qu'elle ait une longueur au moins égale (mais de préférence plus) que le nombre de caractères que va écrire la dll.

---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #    [ Lien ]

Merci très claire, très bien expliqué