[MCD]Limitation de taille de légende [Résolu]

Ithomir · 04/04/2007, 17h47

Bonjour, pour des raisons d'obligations, j'ai dû créer une table avec 170 champs (je sais, c'est énorme, et MERISE, elle est passée où, etc... Je n'ai pas le choix, c'est un critère imposé par le cahier des charges).

Actuellement, quand je tente de créer un nouveau champ (la limite est fixée à 255, pourtant...) je lui mets son petit nom, son type, etc... Mais si je lui colle une légende de plus de 9 caractères, à la sauvegarde, j'ai droit à ce joyeux message :

"La valeur de la propriété est trop grande"
OK/Annuler, puis :
"Erreur pendant l'opération de sauvegarde"
OK

(il me semblait que la légende était limitée à 2048 caractères ??????)

Et ce qui est marrant (... ou pas), c'est que ça arrive pour toute nouvelle insertion de champ, où que ce soit dans la base. J'ai testé en entrant des informations dans la propriété "est valide si", et j'ai le même problème, cette fois limité à 5 caractères.

Existe-t-il une façon de contourner/limiter/détruire/annuler cette limitation ?

EDIT : ça semble lié au nombre de champs : en ajoutant ces champs dans une autre table, ça fonctionne correctement. Par contre après ce bon vieux KOPIKOL, et tentative de sauvegarde... pas mieux.

Philippe JOCHMANS · 05/04/2007, 07h35

Bonjour

Quel est la taille de ta base ?
As-tu atteint les 2 Go de limites ?
As-tu essayer de compacter ?

Starec

Ithomir · 05/04/2007, 09h29

La base est vierge et ne pèse que 10 Mo, c'est bien ce qui m'agace...

Les noms de champs sont de type standard pour permettre un export éventuel. (Nom_champ_standard). Les types de données sont au plus "juste" pour éviter de surcharger la base (type "entier" au lieu de "entier long", ou "réel simple" en lieu et place de "réel double"...etc.).

La table qui me pose problème actuellement contient 179 champs différents (limite fixée à 255 par access, et je dois en avoir 201 au total pour cette table), et à compter du n°179, impossible de mettre une légende de plus de 9 caractères. Si j'insère un champ en position n°2, même problème. On dirait qu'il y a saturation d'une variable quelconque... Mais laquelle ?

Truc amusant, la base vierge est de taille variable : je l'ouvre, je fais un CTRL+S, je la referme, et la taille a varié. Des fois, elle pèse 700 Ko, des fois 35 Mo, c'est bizarre, pour un fichier qui contient les mêmes données, au final. Pour une base vierge de même facture en SQL, la taille reste fixe. Un problème d'Access ?

EDIT : je viens de constater un autre "détail", si j'ajoute un champ supplémentaire, il va chercher la légende du champ qui est au-dessus et me fait le même message d'erreur.

ex : ajout d'un champ nouvel_etat_rejet sans légende. Tentative de sauvegarde : "Message d'erreur". Suppression d'une légende sur un champ (n'importe lequel !), tentative de sauvegarde, tout marche.

alcabk · 05/04/2007, 09h35

au niveau de la taille qui change, j'ai cette surprise aussi... comme te l'a dit starec, il faut la compacter, dans outil/option/général, il faut cocher "compacter lors de la fermeture", elle reprendra alors tjs la même taille. visiblement, le simple fait de la manipuler, fait augmenter la taille.
pour le reste, désolée...

Ithomir · 05/04/2007, 09h55

Elle reprend toujours la même taille, on est d'accord. Par contre, en cochant le "compacter à la fermeture", elle prend 400 Ko de plus, puis elle reste à cette taille.

Ca, c'est du compactage de chez microsoft

Bon, je n'ai plus trop de temps à passer à cehrcher à résoudre ce problème, je vais supprimer les légendes et je vais bosser sans. Mais ça m'en donne, 170 légendes tapées amoureusement de mes petits doigts joufflus.

EDIT de mieux en mieux :s Maintenant, si je sauvegarde... même avec 25 champs "propriété trop grande". Nom de champ le plus long : Regard_controle_bouclage_ecoulement_correct

random · 05/04/2007, 10h23

la limitation ne vient surement pas des légendes mais de ceci

"Nombre de caractères dans un enregistrement (à l'exclusion des champs Mémo et Objet OLE) 2 000" cf spécifications

tu es bon pour scinder ta table en deux ou trois

Ithomir · 05/04/2007, 10h56

La base est vierge, et par définition, je n'ai aucun enregistrement

Accessoirement les noms de légende sont limités à 2048 caractères, j'ai vérifié. (Caption limité à 2048 caractères cf. aide)

loufab · 05/04/2007, 11h07

Attention à la taille de l'enregistrement ! (suivant les versions voir l'aide en lignes mot clef : Limitation, lien limitation des tables)

Cordialement,

Ithomir · 05/04/2007, 11h53

Soit je ne comprends pas ce que veut dire enregistrement, soit sa signification sous access est différente de ma définition.

"Un enregistrement est constitué par les données entrées dans la base de données."

Je ne suis qu'à la phase de conception, et je suis en train de créer les champs dans une table, rien de plus. Suivant ma définition, il n'y a aucun enregistrement.

(J'avais oublié de dire "Merci" pour le compactage à la fermeture, alors "Merci !")

loufab · 05/04/2007, 12h01

L'enregistrement c'est l'ensemble des champs d'une ligne de la table.

Cette taille est limité (2000 caractères pour la version 2002) Il ne faut surtout pas la dépasser sinon tu auras un message d'erreur lorsque l'utilisateur arrivera, en saisie, à la limite.

170 champs caractères limite chaque champ, en moyenne, à +/- 11 caractères.
Avec du numérique suivant le type ça change encore...

Il faut prendre en compte cette règle avant de mettre la MCD en application.

Ithomir · 05/04/2007, 12h18

Merci pour l'explication.

2000 caractères hors mémos et blobs ? Je peux passer certains des champs en mémos, si ça peut changer quelque chose ?

Le cahier des charges est malheureusement très strict sur les champs... Pas moyen d'utiliser un autre modèle conceptuel, ou je me fais taper sur les doigts... Si je change juste les types de données, je ne pense pas que l'on m'en voudra.

(finalement, j'aurais mieux fait d'imposer SQL Server pour le cahier des charges... j'aurais eu le même MCD, mais j'aurais pu réaliser une table avec 200 champs si l'envie m'en avait pris... C'est bien le SQL

)

loufab · 05/04/2007, 13h00

Citation:

Envoyé par Ithomir

2000 caractères hors mémos et blobs ?

Logique puisque les mémos c'est 65535 caractères ou 1Go suivant la méthode de saisie

Et les blobs ? à part The Blob avec Steve McQueen

, je crois qu'on nomme ça Champ OLE !
Egalement puisque ceux-ci sont limités à 1Go (de mémoire, non pas la mémoire RAM ou de Masse... la mienne).

Cordialement,

Ithomir · 05/04/2007, 13h01

Merci pour ta patience. Je vais tenter de faire tout ça, et si ça marche, je mettrai un beau tag "Résolu", promis.

random · 05/04/2007, 13h38

en rajoutant une clef
cela donne
clef+50 champs

réparti en quatre tables, évidemment un peu de soin au niveau de l'indexation
et des relations
cela ne pose aucun problème ton mcd ne souffre en rien
tu gagneras énormément en lisibilité sans altérer les performances de façon sensible tu pourrais même en scindant judicieuceusement les tables et en regroupant dans une table unique les 20% des champs qui font 80% des traitements accroitre trés sensiblement les perfs.

seules les i/o pourraient être un peu plus délicates, mais c'est le prix à payer

Ithomir · 05/04/2007, 13h41

Bah en fait, le cahier des charges m'impose un modèle déterminé, et des tables données avec des champs donnés pour, je cite "pouvoir faire un copier coller du tableau sous Excel"

N'est pas spécialiste en BDD qui veut... J'ai bien précisé qu'on pouvait faire un export vers Excel, mais "non, nous on veut pouvoir trifouiller et tout lire tranquillement directement dans access". Donc mon beaaaau modèle que j'avais créé sur papier, avec liens vers d'autres tables, et optimisation, pour cette belle table à 170 champs est passé à la trappe.

Par contre, j'ai toute liberté pour les types de données des champs, ça n'est mentionné nulle part. Donc...

Ithomir · 05/04/2007, 15h47

J'ai remplacé certains champs de type texte par des type mémos (tout plein) pour éviter des problèmes lors de la saisie.

Ce qui n'avait pas été précisé, c'est qu'Access limite à un certain nombre de caractères dans une seule table le total de caractères des :
-noms de champs
-légendes
-listes de valeurs
-noms de requêtes

J'ignore si d'autres paramètres sont pris en compte, mais en jouant sur ces quatre-là, j'ai réussi.

random · 05/04/2007, 16h11

à mon avis c'est une victoire à la pyrrhus
tu vas au devant de graves ennuis
les champs mémos c'est bien pour des données descriptives(notes,commentaires)

pour de la gestion c'est la galère

Ithomir · 05/04/2007, 17h31

Je te rassure tout de suite, j'aurais préféré faire un vrai modèle de conception pour cette "table" qui est à elle seule une base de données.

J'aurais également préféré me servir de SQL Server plutôt que d'utiliser Access. Le choix ne m'a pas été donné.

04/04/2007, 17h47	#1
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	[MCD]Limitation de taille de légende Bonjour, pour des raisons d'obligations, j'ai dû créer une table avec 170 champs (je sais, c'est énorme, et MERISE, elle est passée où, etc... Je n'ai pas le choix, c'est un critère imposé par le cahier des charges). Actuellement, quand je tente de créer un nouveau champ (la limite est fixée à 255, pourtant...) je lui mets son petit nom, son type, etc... Mais si je lui colle une légende de plus de 9 caractères, à la sauvegarde, j'ai droit à ce joyeux message : "La valeur de la propriété est trop grande" OK/Annuler, puis : "Erreur pendant l'opération de sauvegarde" OK (il me semblait que la légende était limitée à 2048 caractères ??????) Et ce qui est marrant (... ou pas), c'est que ça arrive pour toute nouvelle insertion de champ, où que ce soit dans la base. J'ai testé en entrant des informations dans la propriété "est valide si", et j'ai le même problème, cette fois limité à 5 caractères. Existe-t-il une façon de contourner/limiter/détruire/annuler cette limitation ? EDIT : ça semble lié au nombre de champs : en ajoutant ces champs dans une autre table, ça fonctionne correctement. Par contre après ce bon vieux KOPIKOL, et tentative de sauvegarde... pas mieux.
	00

05/04/2007, 07h35	#2
Philippe JOCHMANS Rédacteur/Modérateur Philippe JOCHMANS Développeur informatique Inscription : mai 2005 Messages : 17 625 Détails du profil Informations personnelles : Nom : Philippe JOCHMANS Âge : 44 Localisation : France, Loir et Cher (Centre) Informations professionnelles : Activité : Développeur informatique Secteur : Communication - Médias Informations forums : Inscription : mai 2005 Messages : 17 625 Points : 30 922 Points : 30 922	Bonjour Quel est la taille de ta base ? As-tu atteint les 2 Go de limites ? As-tu essayer de compacter ? Starec __________________ Détaillez vos questions, sinon vous aurez des réponses erronées et vous irez tout droit dans le et lisez les règles sinon Si vous pensez commencer sans un livre, oublier : livres pour débuter Vous pouvez consulter mes articles sur Access et PowerPoint Le blog Office.
	00

05/04/2007, 09h29	#3
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	mmm La base est vierge et ne pèse que 10 Mo, c'est bien ce qui m'agace... Les noms de champs sont de type standard pour permettre un export éventuel. (Nom_champ_standard). Les types de données sont au plus "juste" pour éviter de surcharger la base (type "entier" au lieu de "entier long", ou "réel simple" en lieu et place de "réel double"...etc.). La table qui me pose problème actuellement contient 179 champs différents (limite fixée à 255 par access, et je dois en avoir 201 au total pour cette table), et à compter du n°179, impossible de mettre une légende de plus de 9 caractères. Si j'insère un champ en position n°2, même problème. On dirait qu'il y a saturation d'une variable quelconque... Mais laquelle ? Truc amusant, la base vierge est de taille variable : je l'ouvre, je fais un CTRL+S, je la referme, et la taille a varié. Des fois, elle pèse 700 Ko, des fois 35 Mo, c'est bizarre, pour un fichier qui contient les mêmes données, au final. Pour une base vierge de même facture en SQL, la taille reste fixe. Un problème d'Access ? EDIT : je viens de constater un autre "détail", si j'ajoute un champ supplémentaire, il va chercher la légende du champ qui est au-dessus et me fait le même message d'erreur. ex : ajout d'un champ nouvel_etat_rejet sans légende. Tentative de sauvegarde : "Message d'erreur". Suppression d'une légende sur un champ (n'importe lequel !), tentative de sauvegarde, tout marche.
	00

05/04/2007, 10h23	#6
random Expert Confirmé Inscription : mai 2005 Messages : 3 419 Détails du profil Informations forums : Inscription : mai 2005 Messages : 3 419 Points : 3 768 Points : 3 768	la limitation ne vient surement pas des légendes mais de ceci "Nombre de caractères dans un enregistrement (à l'exclusion des champs Mémo et Objet OLE) 2 000" cf spécifications tu es bon pour scinder ta table en deux ou trois __________________ Elle est pas belle la vie ?
	00

05/04/2007, 11h07	#8
loufab Rédacteur/Modérateur Fabrice CONSTANS Ingénieur développement logiciels Inscription : avril 2005 Messages : 7 096 Détails du profil Informations personnelles : Nom : Fabrice CONSTANS Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Ingénieur développement logiciels Informations forums : Inscription : avril 2005 Messages : 7 096 Points : 11 628 Points : 11 628	Attention à la taille de l'enregistrement ! (suivant les versions voir l'aide en lignes mot clef : Limitation, lien limitation des tables) Cordialement, __________________ Classe MELA(CRUD) Opérateur IN et zone de liste MsGraph et VBA - 1e Partie 2e partie Entête d'états-Opérateur LIKE-Evénements formulaires-Cours 2010 Complément :Générateur de msgbox Visitez mon Blog Les questions techniques par MP ne sont pas lues et je ne pratique pas l'extispicine
	00

05/04/2007, 09h35	#4
alcabk Membre habitué Inscription : juin 2006 Messages : 174 Détails du profil Informations forums : Inscription : juin 2006 Messages : 174 Points : 146 Points : 146	au niveau de la taille qui change, j'ai cette surprise aussi... comme te l'a dit starec, il faut la compacter, dans outil/option/général, il faut cocher "compacter lors de la fermeture", elle reprendra alors tjs la même taille. visiblement, le simple fait de la manipuler, fait augmenter la taille. pour le reste, désolée...
	00

05/04/2007, 09h55	#5
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Elle reprend toujours la même taille, on est d'accord. Par contre, en cochant le "compacter à la fermeture", elle prend 400 Ko de plus, puis elle reste à cette taille. Ca, c'est du compactage de chez microsoft Bon, je n'ai plus trop de temps à passer à cehrcher à résoudre ce problème, je vais supprimer les légendes et je vais bosser sans. Mais ça m'en donne, 170 légendes tapées amoureusement de mes petits doigts joufflus. EDIT de mieux en mieux :s Maintenant, si je sauvegarde... même avec 25 champs "propriété trop grande". Nom de champ le plus long : Regard_controle_bouclage_ecoulement_correct
	00

05/04/2007, 10h56	#7
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	La base est vierge, et par définition, je n'ai aucun enregistrement Accessoirement les noms de légende sont limités à 2048 caractères, j'ai vérifié. (Caption limité à 2048 caractères cf. aide)
	00

05/04/2007, 11h53	#9
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Soit je ne comprends pas ce que veut dire enregistrement, soit sa signification sous access est différente de ma définition. "Un enregistrement est constitué par les données entrées dans la base de données." Je ne suis qu'à la phase de conception, et je suis en train de créer les champs dans une table, rien de plus. Suivant ma définition, il n'y a aucun enregistrement. (J'avais oublié de dire "Merci" pour le compactage à la fermeture, alors "Merci !")
	00

05/04/2007, 12h01	#10
loufab Rédacteur/Modérateur Fabrice CONSTANS Ingénieur développement logiciels Inscription : avril 2005 Messages : 7 096 Détails du profil Informations personnelles : Nom : Fabrice CONSTANS Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Ingénieur développement logiciels Informations forums : Inscription : avril 2005 Messages : 7 096 Points : 11 628 Points : 11 628	L'enregistrement c'est l'ensemble des champs d'une ligne de la table. Cette taille est limité (2000 caractères pour la version 2002) Il ne faut surtout pas la dépasser sinon tu auras un message d'erreur lorsque l'utilisateur arrivera, en saisie, à la limite. 170 champs caractères limite chaque champ, en moyenne, à +/- 11 caractères. Avec du numérique suivant le type ça change encore... Il faut prendre en compte cette règle avant de mettre la MCD en application. __________________ Classe MELA(CRUD) Opérateur IN et zone de liste MsGraph et VBA - 1e Partie 2e partie Entête d'états-Opérateur LIKE-Evénements formulaires-Cours 2010 Complément :Générateur de msgbox Visitez mon Blog Les questions techniques par MP ne sont pas lues et je ne pratique pas l'extispicine
	00

05/04/2007, 12h18	#11
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Merci pour l'explication. 2000 caractères hors mémos et blobs ? Je peux passer certains des champs en mémos, si ça peut changer quelque chose ? Le cahier des charges est malheureusement très strict sur les champs... Pas moyen d'utiliser un autre modèle conceptuel, ou je me fais taper sur les doigts... Si je change juste les types de données, je ne pense pas que l'on m'en voudra. (finalement, j'aurais mieux fait d'imposer SQL Server pour le cahier des charges... j'aurais eu le même MCD, mais j'aurais pu réaliser une table avec 200 champs si l'envie m'en avait pris... C'est bien le SQL )
	00

05/04/2007, 13h01	#13
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Merci pour ta patience. Je vais tenter de faire tout ça, et si ça marche, je mettrai un beau tag "Résolu", promis.
	00

05/04/2007, 13h38	#14
random Expert Confirmé Inscription : mai 2005 Messages : 3 419 Détails du profil Informations forums : Inscription : mai 2005 Messages : 3 419 Points : 3 768 Points : 3 768	en rajoutant une clef cela donne clef+50 champs réparti en quatre tables, évidemment un peu de soin au niveau de l'indexation et des relations cela ne pose aucun problème ton mcd ne souffre en rien tu gagneras énormément en lisibilité sans altérer les performances de façon sensible tu pourrais même en scindant judicieuceusement les tables et en regroupant dans une table unique les 20% des champs qui font 80% des traitements accroitre trés sensiblement les perfs. seules les i/o pourraient être un peu plus délicates, mais c'est le prix à payer __________________ Elle est pas belle la vie ?
	00

05/04/2007, 13h41	#15
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Bah en fait, le cahier des charges m'impose un modèle déterminé, et des tables données avec des champs donnés pour, je cite "pouvoir faire un copier coller du tableau sous Excel" N'est pas spécialiste en BDD qui veut... J'ai bien précisé qu'on pouvait faire un export vers Excel, mais "non, nous on veut pouvoir trifouiller et tout lire tranquillement directement dans access". Donc mon beaaaau modèle que j'avais créé sur papier, avec liens vers d'autres tables, et optimisation, pour cette belle table à 170 champs est passé à la trappe. Par contre, j'ai toute liberté pour les types de données des champs, ça n'est mentionné nulle part. Donc...
	00

05/04/2007, 15h47	#16
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	J'ai remplacé certains champs de type texte par des type mémos (tout plein) pour éviter des problèmes lors de la saisie. Ce qui n'avait pas été précisé, c'est qu'Access limite à un certain nombre de caractères dans une seule table le total de caractères des : -noms de champs -légendes -listes de valeurs -noms de requêtes J'ignore si d'autres paramètres sont pris en compte, mais en jouant sur ces quatre-là, j'ai réussi.
	00

05/04/2007, 16h11	#17
random Expert Confirmé Inscription : mai 2005 Messages : 3 419 Détails du profil Informations forums : Inscription : mai 2005 Messages : 3 419 Points : 3 768 Points : 3 768	à mon avis c'est une victoire à la pyrrhus tu vas au devant de graves ennuis les champs mémos c'est bien pour des données descriptives(notes,commentaires) pour de la gestion c'est la galère __________________ Elle est pas belle la vie ?
	00

05/04/2007, 17h31	#18
Ithomir Invité régulier Inscription : février 2006 Messages : 35 Détails du profil Informations forums : Inscription : février 2006 Messages : 35 Points : 9 Points : 9	Je te rassure tout de suite, j'aurais préféré faire un vrai modèle de conception pour cette "table" qui est à elle seule une base de données. J'aurais également préféré me servir de SQL Server plutôt que d'utiliser Access. Le choix ne m'a pas été donné.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email