OVH Cloud OVH Cloud

Message E-FAIL

9 réponses
Avatar
Mofi
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des formulaires de
+/- 50 000 enregistrement (codes postaux), j'ai systématiquement un message
d'ereeur E-FAIL. Le compteur se bloque aléatoirement sur 1 900, 47 000,
1200, etc... avant d'envoyer ce p..... de message. J'ai beau chercher dans
les fils de newsgroup, dans l'aide, dans mes bouquins, je ne trouve même pas
à quoi cela peut correspondre. La source du formulaire est pourtant tout
simplement une requête sur une seule table triée dans l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.

9 réponses

Avatar
Sylvain Lafontaine
Peut-être que quelques détails sur la techique utilisée pourraient nous être
utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des formulaires
de +/- 50 000 enregistrement (codes postaux), j'ai systématiquement un
message d'ereeur E-FAIL. Le compteur se bloque aléatoirement sur 1 900, 47
000, 1200, etc... avant d'envoyer ce p..... de message. J'ai beau chercher
dans les fils de newsgroup, dans l'aide, dans mes bouquins, je ne trouve
même pas à quoi cela peut correspondre. La source du formulaire est
pourtant tout simplement une requête sur une seule table triée dans
l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.



Avatar
Mofi
Merci de répondre aussi vite !!

avec quels éléments techniques puis-je vous être utile afin de m'être utile
?


"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des formulaires
de +/- 50 000 enregistrement (codes postaux), j'ai systématiquement un
message d'ereeur E-FAIL. Le compteur se bloque aléatoirement sur 1 900,
47 000, 1200, etc... avant d'envoyer ce p..... de message. J'ai beau
chercher dans les fils de newsgroup, dans l'aide, dans mes bouquins, je
ne trouve même pas à quoi cela peut correspondre. La source du formulaire
est pourtant tout simplement une requête sur une seule table triée dans
l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.







Avatar
Mofi
Merci de répondre aussi vite,

quels éléments tecchniques pourraient vous être utiles afin de m'être utile
?


"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des formulaires
de +/- 50 000 enregistrement (codes postaux), j'ai systématiquement un
message d'ereeur E-FAIL. Le compteur se bloque aléatoirement sur 1 900,
47 000, 1200, etc... avant d'envoyer ce p..... de message. J'ai beau
chercher dans les fils de newsgroup, dans l'aide, dans mes bouquins, je
ne trouve même pas à quoi cela peut correspondre. La source du formulaire
est pourtant tout simplement une requête sur une seule table triée dans
l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.







Avatar
Mofi
Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
messages mettent 10 mn à partir

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des formulaires
de +/- 50 000 enregistrement (codes postaux), j'ai systématiquement un
message d'ereeur E-FAIL. Le compteur se bloque aléatoirement sur 1 900,
47 000, 1200, etc... avant d'envoyer ce p..... de message. J'ai beau
chercher dans les fils de newsgroup, dans l'aide, dans mes bouquins, je
ne trouve même pas à quoi cela peut correspondre. La source du formulaire
est pourtant tout simplement une requête sur une seule table triée dans
l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.







Avatar
Sylvain Lafontaine
Comme détails, on a l'embarras du choix: vous pourriez nous dire si vous
essayez de lire tous les enregistrements d'un coup ou non; si vous avez
modifié ou non la valeur limite de 10000 enregistrements (50000
enregistrements, cela peut être beaucoup; votre machine manque peut-être de
mémoire); c'est quoi la requête source utilisée dans le formulaire; si vous
avez défini une clef primaire sur votre table, si l'ordre de tri est dans le
formulaire ou dans la requête elle-même; si vous êtes sur un LAN ou sur un
WAN avec possibilité de time-out; etc.

S. L.

"Mofi" wrote in message
news:415c7797$0$1442$
Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
messages mettent 10 mn à partir

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des
formulaires de +/- 50 000 enregistrement (codes postaux), j'ai
systématiquement un message d'ereeur E-FAIL. Le compteur se bloque
aléatoirement sur 1 900, 47 000, 1200, etc... avant d'envoyer ce p.....
de message. J'ai beau chercher dans les fils de newsgroup, dans l'aide,
dans mes bouquins, je ne trouve même pas à quoi cela peut correspondre.
La source du formulaire est pourtant tout simplement une requête sur une
seule table triée dans l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.











Avatar
Mofi
Ok, Ok,

En fait, c'est la seule table qui me pose souci. Il y a 76000
enregistrements.
la structure de la table est simplissime : cpl_code en clé primaire,
cpl_ville en texte, et cpl_pays en clé externe (table pays)

la source du form est du même accabit :
SELECT cp.*,p.pays_nom

FROM dbo.tbl_codes_postaux AS cp INNER JOIN

dbo.tbl_pays AS p ON

cp.ID_pays = p.ID_pays

WHERE cp.ID_pays = @flt_pays

ORDER BY cpl_code

j'ai positionné le type recordset en instané en le nb max d'enr à 0 (essayé
en 10.000, 50.000, 100.000, même résultat)

En ouvrant la table directement sans limite d'enr, ou en éxécutant le
requête ci-dessus, elle met 5 secondes à aller jusqu'au bout avec un oic de
mémoire à 37 %.

en ouvrant le formulaire le compteur d'enr se bloque de suite sur un nombre
d'enr aléatoire, et le cpu est juste au dessus de 50% d'utilisation pendant
quelques secondes, avant d'afficher "Erreur E-FAIL"

Je n'ai pourtant pas trouvé de complexité particulière dans cette requête
!!!

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:

Comme détails, on a l'embarras du choix: vous pourriez nous dire si vous
essayez de lire tous les enregistrements d'un coup ou non; si vous avez
modifié ou non la valeur limite de 10000 enregistrements (50000
enregistrements, cela peut être beaucoup; votre machine manque peut-être
de mémoire); c'est quoi la requête source utilisée dans le formulaire; si
vous avez défini une clef primaire sur votre table, si l'ordre de tri est
dans le formulaire ou dans la requête elle-même; si vous êtes sur un LAN
ou sur un WAN avec possibilité de time-out; etc.

S. L.

"Mofi" wrote in message
news:415c7797$0$1442$
Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
messages mettent 10 mn à partir

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des
formulaires de +/- 50 000 enregistrement (codes postaux), j'ai
systématiquement un message d'ereeur E-FAIL. Le compteur se bloque
aléatoirement sur 1 900, 47 000, 1200, etc... avant d'envoyer ce p.....
de message. J'ai beau chercher dans les fils de newsgroup, dans l'aide,
dans mes bouquins, je ne trouve même pas à quoi cela peut correspondre.
La source du formulaire est pourtant tout simplement une requête sur
une seule table triée dans l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.















Avatar
bruno reiter [MVP]
le code postal n'est pas une bonne PK puisqu'il y a le même code pour
plusieurs communes peut etre ça?

br

"Mofi" wrote in message
news:415d388b$0$9468$
Ok, Ok,

En fait, c'est la seule table qui me pose souci. Il y a 76000
enregistrements.
la structure de la table est simplissime : cpl_code en clé primaire,
cpl_ville en texte, et cpl_pays en clé externe (table pays)

la source du form est du même accabit :
SELECT cp.*,p.pays_nom

FROM dbo.tbl_codes_postaux AS cp INNER JOIN

dbo.tbl_pays AS p ON

cp.ID_pays = p.ID_pays

WHERE cp.ID_pays = @flt_pays

ORDER BY cpl_code

j'ai positionné le type recordset en instané en le nb max d'enr à 0


(essayé
en 10.000, 50.000, 100.000, même résultat)

En ouvrant la table directement sans limite d'enr, ou en éxécutant le
requête ci-dessus, elle met 5 secondes à aller jusqu'au bout avec un oic


de
mémoire à 37 %.

en ouvrant le formulaire le compteur d'enr se bloque de suite sur un


nombre
d'enr aléatoire, et le cpu est juste au dessus de 50% d'utilisation


pendant
quelques secondes, avant d'afficher "Erreur E-FAIL"

Je n'ai pourtant pas trouvé de complexité particulière dans cette requête
!!!

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:

> Comme détails, on a l'embarras du choix: vous pourriez nous dire si vous
> essayez de lire tous les enregistrements d'un coup ou non; si vous avez
> modifié ou non la valeur limite de 10000 enregistrements (50000
> enregistrements, cela peut être beaucoup; votre machine manque peut-être
> de mémoire); c'est quoi la requête source utilisée dans le formulaire;


si
> vous avez défini une clef primaire sur votre table, si l'ordre de tri


est
> dans le formulaire ou dans la requête elle-même; si vous êtes sur un LAN
> ou sur un WAN avec possibilité de time-out; etc.
>
> S. L.
>
> "Mofi" wrote in message
> news:415c7797$0$1442$
>> Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
>> messages mettent 10 mn à partir
>>
>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>


a
>> écrit dans le message de news:
>>> Peut-être que quelques détails sur la techique utilisée pourraient


nous
>>> être utiles ici?
>>>
>>> S. L.
>>>
>>> "Mofi" wrote in message
>>> news:415c67c9$0$3677$
>>>> Bonjour à tous,
>>>>
>>>> Je travaille sur SQL server avec un projet Access. Sur un des
>>>> formulaires de +/- 50 000 enregistrement (codes postaux), j'ai
>>>> systématiquement un message d'ereeur E-FAIL. Le compteur se bloque
>>>> aléatoirement sur 1 900, 47 000, 1200, etc... avant d'envoyer ce


p.....
>>>> de message. J'ai beau chercher dans les fils de newsgroup, dans


l'aide,
>>>> dans mes bouquins, je ne trouve même pas à quoi cela peut


correspondre.
>>>> La source du formulaire est pourtant tout simplement une requête sur
>>>> une seule table triée dans l'ordre.
>>>> Pouvez-vous SVP me tirer de mon désarroi ?
>>>>
>>>> je vous remercie d'avance pour vos précieuses lumières.
>>>>
>>>
>>>
>>
>>
>
>




Avatar
Sylvain Lafontaine
Très simple, en effet.

1- Il se peut que votre programme manque de mémoire: le nombre
d'enregistrements affiché est-il vraiment aléatoire ou s'il dépend du
paramètre envoyé?

Y a-t-il suffisamment de la place pour la table tmp du SQL-Server?

Les autres tables qui fonctionnent sans aucun problème ont-elles un
nombre équivalent ou supérieur d'enregistrements pouvant être retournés?

Utilisez-vous toujours Access 2000, cela malgré les très nombreux avis
de bugs internes ou si vous avez passé à A2002/2003?

J'imagine aussi que vous faites un usage fréquent et très libéral de la
fonction F5-Refresh (menu View) dans la liste des requêtes.

2- Comment avez-vous défini votre requête source dans votre forme;
directement avec le nom de la procédure ou avec un EXEC? Cette requête
est-elle exprimée sous la forme d'une procédure stockée ou directement en
tant que code source SQL?

Y a-t-il un mélange de code ASCII et UNICODE (varchar vs nvarchar) dans la
définition de votre clef primaire?

3- Il y a peut-être eu corruption dans la compilation du code: essayer de
décompiler puis de recompiler votre code. Quelle librairie d'ADO
utilisez-vous en référence? Essayez également de créer une nouvelle forme
basée sur la même requête.

4- Avez-vous mis un ordre de tri dans votre formulaire ou seulement dans la
procédure stockée?

"Mofi" wrote in message
news:415d388b$0$9468$
Ok, Ok,

En fait, c'est la seule table qui me pose souci. Il y a 76000
enregistrements.
la structure de la table est simplissime : cpl_code en clé primaire,
cpl_ville en texte, et cpl_pays en clé externe (table pays)

la source du form est du même accabit :
SELECT cp.*,p.pays_nom

FROM dbo.tbl_codes_postaux AS cp INNER JOIN

dbo.tbl_pays AS p ON

cp.ID_pays = p.ID_pays

WHERE cp.ID_pays = @flt_pays

ORDER BY cpl_code

j'ai positionné le type recordset en instané en le nb max d'enr à 0
(essayé en 10.000, 50.000, 100.000, même résultat)

En ouvrant la table directement sans limite d'enr, ou en éxécutant le
requête ci-dessus, elle met 5 secondes à aller jusqu'au bout avec un oic
de mémoire à 37 %.

en ouvrant le formulaire le compteur d'enr se bloque de suite sur un
nombre d'enr aléatoire, et le cpu est juste au dessus de 50% d'utilisation
pendant quelques secondes, avant d'afficher "Erreur E-FAIL"

Je n'ai pourtant pas trouvé de complexité particulière dans cette requête
!!!

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:

Comme détails, on a l'embarras du choix: vous pourriez nous dire si vous
essayez de lire tous les enregistrements d'un coup ou non; si vous avez
modifié ou non la valeur limite de 10000 enregistrements (50000
enregistrements, cela peut être beaucoup; votre machine manque peut-être
de mémoire); c'est quoi la requête source utilisée dans le formulaire; si
vous avez défini une clef primaire sur votre table, si l'ordre de tri est
dans le formulaire ou dans la requête elle-même; si vous êtes sur un LAN
ou sur un WAN avec possibilité de time-out; etc.

S. L.

"Mofi" wrote in message
news:415c7797$0$1442$
Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
messages mettent 10 mn à partir

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
a écrit dans le message de news:

Peut-être que quelques détails sur la techique utilisée pourraient nous
être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des
formulaires de +/- 50 000 enregistrement (codes postaux), j'ai
systématiquement un message d'ereeur E-FAIL. Le compteur se bloque
aléatoirement sur 1 900, 47 000, 1200, etc... avant d'envoyer ce
p..... de message. J'ai beau chercher dans les fils de newsgroup, dans
l'aide, dans mes bouquins, je ne trouve même pas à quoi cela peut
correspondre. La source du formulaire est pourtant tout simplement une
requête sur une seule table triée dans l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.



















Avatar
Mofi
C'est tout bon. Merci infiniment de votre patience.
En fait, j'ai recrée un nouveau forme identique en remettant la procédure
stockée en source, ça marche au poil. Il y a du avoir une corruption quelque
part.

Je garde tout de même cette check-list pour d'éventuels besoins futurs.

Merci encore

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news: ew$$
Très simple, en effet.

1- Il se peut que votre programme manque de mémoire: le nombre
d'enregistrements affiché est-il vraiment aléatoire ou s'il dépend du
paramètre envoyé?

Y a-t-il suffisamment de la place pour la table tmp du SQL-Server?

Les autres tables qui fonctionnent sans aucun problème ont-elles un
nombre équivalent ou supérieur d'enregistrements pouvant être retournés?

Utilisez-vous toujours Access 2000, cela malgré les très nombreux avis
de bugs internes ou si vous avez passé à A2002/2003?

J'imagine aussi que vous faites un usage fréquent et très libéral de la
fonction F5-Refresh (menu View) dans la liste des requêtes.

2- Comment avez-vous défini votre requête source dans votre forme;
directement avec le nom de la procédure ou avec un EXEC? Cette requête
est-elle exprimée sous la forme d'une procédure stockée ou directement en
tant que code source SQL?

Y a-t-il un mélange de code ASCII et UNICODE (varchar vs nvarchar) dans la
définition de votre clef primaire?

3- Il y a peut-être eu corruption dans la compilation du code: essayer de
décompiler puis de recompiler votre code. Quelle librairie d'ADO
utilisez-vous en référence? Essayez également de créer une nouvelle forme
basée sur la même requête.

4- Avez-vous mis un ordre de tri dans votre formulaire ou seulement dans
la procédure stockée?

"Mofi" wrote in message
news:415d388b$0$9468$
Ok, Ok,

En fait, c'est la seule table qui me pose souci. Il y a 76000
enregistrements.
la structure de la table est simplissime : cpl_code en clé primaire,
cpl_ville en texte, et cpl_pays en clé externe (table pays)

la source du form est du même accabit :
SELECT cp.*,p.pays_nom

FROM dbo.tbl_codes_postaux AS cp INNER JOIN

dbo.tbl_pays AS p ON

cp.ID_pays = p.ID_pays

WHERE cp.ID_pays = @flt_pays

ORDER BY cpl_code

j'ai positionné le type recordset en instané en le nb max d'enr à 0
(essayé en 10.000, 50.000, 100.000, même résultat)

En ouvrant la table directement sans limite d'enr, ou en éxécutant le
requête ci-dessus, elle met 5 secondes à aller jusqu'au bout avec un oic
de mémoire à 37 %.

en ouvrant le formulaire le compteur d'enr se bloque de suite sur un
nombre d'enr aléatoire, et le cpu est juste au dessus de 50%
d'utilisation pendant quelques secondes, avant d'afficher "Erreur E-FAIL"

Je n'ai pourtant pas trouvé de complexité particulière dans cette requête
!!!

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:

Comme détails, on a l'embarras du choix: vous pourriez nous dire si vous
essayez de lire tous les enregistrements d'un coup ou non; si vous avez
modifié ou non la valeur limite de 10000 enregistrements (50000
enregistrements, cela peut être beaucoup; votre machine manque peut-être
de mémoire); c'est quoi la requête source utilisée dans le formulaire;
si vous avez défini une clef primaire sur votre table, si l'ordre de tri
est dans le formulaire ou dans la requête elle-même; si vous êtes sur un
LAN ou sur un WAN avec possibilité de time-out; etc.

S. L.

"Mofi" wrote in message
news:415c7797$0$1442$
Désolé pour le doublon, depuis que j'ai installé SP2, les réponses aux
messages mettent 10 mn à partir

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
a écrit dans le message de news:

Peut-être que quelques détails sur la techique utilisée pourraient
nous être utiles ici?

S. L.

"Mofi" wrote in message
news:415c67c9$0$3677$
Bonjour à tous,

Je travaille sur SQL server avec un projet Access. Sur un des
formulaires de +/- 50 000 enregistrement (codes postaux), j'ai
systématiquement un message d'ereeur E-FAIL. Le compteur se bloque
aléatoirement sur 1 900, 47 000, 1200, etc... avant d'envoyer ce
p..... de message. J'ai beau chercher dans les fils de newsgroup,
dans l'aide, dans mes bouquins, je ne trouve même pas à quoi cela
peut correspondre. La source du formulaire est pourtant tout
simplement une requête sur une seule table triée dans l'ordre.
Pouvez-vous SVP me tirer de mon désarroi ?

je vous remercie d'avance pour vos précieuses lumières.