Discussion :

[Vijinn]

Bonjour à tous.

Je me désespère.
Depuis ce midi, sans explication, je ne peux plus modifier de données dans une de mes tables : il me mets "l'enregistrement est trop long" alors que je n'ai qu'une dizaine de champs, que les 3/4 sont vides et que, de toute façon, je veux juste enlever un "s" à un mot ! et ça me fait ça dans n'importe quel champ de cette table (les autres tables, c'est bon) !

Qu'est-ce que c'est que ce micmac ?
Des idées ?

[marot_r]

Bonjour.

Fais une sauvegarde de ta BD puis demande un compactage.

Il se peut que ton enregistrement (ou un autre) soit endommagé.

Si le compactage ne donne rien, tu peux essayer une requête de mise à jour en lieu et place d'une saisie directe.

A+

[doubleface2]

bsr
reverifies la longueur des champs

[Vijinn]

Bonjour et merci de votre réponse.

Tout d'abord, il ne peut s'agir d'une mauvaise caractérisation des champs (genre longueur limitée, etc.) puisqu'il empêche toute modification de champs déjà remplis, même la simple suppression d'une lettre et répond invariablement "l'enregistrement est trop long"... même pour un champ texte de 255 caractères dont la valeur n'a que 6 lettres.

La semaine dernière, le lendemain de l'apparition du problème, celui-ci avait disparu ! On pouvait à nouveau entrer des données normalement.
Mais aujourd'hui, voilà qu'il recommence : sur le même formulaire, sans explication, alors qu'un quart d'heure avant c'était encore bon, voilà qu'il me bloque à nouveau toute saisie de donnée en affichant "l'enregistrement est trop long" ! Ma base ne fait pourtant que quelques dizaines d'enregistrements et pèse en tout 33000 Ko !
Autre problème que je viens de remarquer : quand j'ouvre ce même formulaire, je me rends compte que la donnée du premier champ du premier enregistrement a été altérée ("Fossé" est transformé en "F ").

Je n'ai vraiment aucune explication.

J'ai essayé de compacter sur les conseils de marot_r, et ça semble fonctionner : on peut à nouveau entrer des données... jusqu'à la prochaine fois !
Il est donc possible que ma base soit endommagée ou que ça ait un lien avec le réseau de ma boite qui sature un peu, ou avec ma session utilisateur qui soit mal paramétrée par mon gestionnaire réseau, ou etc.

Merci de votre écoute, je laisse cette discussion ouverte si quelqu'un a une idée...

[loufab]

Bonjour,

Il se peut que ce soit un problème lié au formulaire, à la manière de l'utiliser ou encore à une source qui pose problème.

Il se peut que ton formulaire soit endommagé.

1) faire un decomp/comp de l'appli, la méthode est sur mon blog : http://blogaccess.free.fr/?p=75
2) souvent des copier/coller de texte à partir du net ou d'autres sources peuvent intégrer des caractères spéciaux qui foutent la grouille dans l'enregistrement.
3) réécrire la source et remettre des contrôles tout neuf.
4) Faire un import/export texte du formulaire, Attention ! perte des macros incorporées : http://www.developpez.net/forums/d15...s-incorporees/

J'ai personnellement un problème aléatoire sur une de mes applis en exploitation. De temps à autre un enregistrement se met en carafe avec apparition de caractères chinois, la seule méthode est la suppression du record.

Quand tu dis "mon appli fait 33 Mo pour 10 records" tu laisse entendre que tu as tous dans le même fichier, tables et ihm. Est-ce le cas ? Si oui adopte de suite une archi frontale/dorsale. C'est la base.

Cordialement,

[loufab]

Si ça ne résout pas, j'ai quelques autres pistes.

[Vijinn]

Merci de ton éclairage.

Pour l'instant, le problème a disparu après le compactage. J'essayerai l'une ou l'autre de tes procédures lorsque le problème se présentera à nouveau. Je précise que le problème ne semble pas venir du formulaire, ni même de la requête, puisque même une tentative de saisie dans la table est refusée.

Ensuite, comme cette base de données est en cours d'élaboration, que j'ai toujours besoin de trifouiller les formulaires, les requêtes et mêmes les tables, et surtout que je suis un novice en base de données, alors oui, je n'ai pas encore divisé mon architecture en frontale / dorsale, même si cela sera prévu en fin d'élaboration.

Suite au prochain numéro...

[loufab]

Je remarque 2 choses dans tes indications :

Pour l'instant, le problème a disparu après le compactage. J'essayerai l'une ou l'autre de tes procédures lorsque le problème se présentera à nouveau. Je précise que le problème ne semble pas venir du formulaire, ni même de la requête, puisque même une tentative de saisie dans la table est refusée.

Le problème peut venir de l'ihm, en effet tu véroles la table à un instant T (une manip particulière ?) du coup il faut attendre un compactage pour remettre le tout d'aplomb.

... que j'ai toujours besoin de trifouiller les formulaires...

C'est le cas classique pour provoquer un problème dans l'ihm. Déjà constaté de nombreuses fois, surtout lorsqu'on utilise des méthodes qui sont borderline. Utilisation de la mauvaise propriété, traitement inadapté...

Fait des decomp/comp régulier. La méthode que j'indique sur mon blog fait une sauvegarde avant l'opération de decomp (c'est la plus risquée) si le SET MS/DOS est traité dans ton appli elle ne s'exécute pas, ce qui est essentiel avant d'entamer le compactage. Donc aucun risque de perdre l'appli, au pire tu repars de la sauve qu'il a généré (une simple copie) et tu traite manuellement le problème.

Cordialement,

[Vijinn]

Le problème vient en effet peut-être d'un formulaire : c'est apparu la première fois après avoir mis un code VBA tout bête qui attribuait une valeur à un champ si un champ case à cocher était sur True. Un code simplissime, quoi. Lors de l'exécution, il a commencé à me mettre des messages d'erreur dont je ne me rappelle plus la teneur, puis toute saisie est devenue impossible avec le fameux message "enregistrement trop long".
En tout cas, je suis bien aise de voir que ce type de problème inexplicable semble arriver à d'autre que moi.

Merci de tes conseils, je clos cette discussion, j'y reviendrai si j'ai du nouveau.