[Résolu] Prise en compte des tirets dans formulaire

[camil]

Le titre de votre question n'est pas assez explicite :
<Problème avec tiret>
Nous l'avons donc modifié. En effet, lors d'une recherche, ce sujet risquait de passer inaperçu et donc de ne pas aider d'autres personnes ayant le même problème que vous.
Les termes implicites comme problème n'ont pas besoin d'être mentionnés.

onjour,
Je ne sais ni comment intituler ce sujet ni où le déposer. Je compte sur vous pour remédier à çà...
Je suis novice, que ça soit dit
Je commence une base sur LibreOffice 6.5.1.2 sous Windows 10, pour tenir mes comptes persos. Voici le problème qui me fait craquer :
J'ai, entre autres, deux tables : 1 pour mes comptes et 1 pour mes journaux et 1 formulaire de saisie pour chacune.
Pour nommer mes comptes et mes journaux dans chaque tables j'ai respectivement 1 champ NomCompte et 1 champ NomJournal; chacun des deux étant du type VARCHAR.
Lorsque je saisis, dans mon formulaire F_Journaux le nom du journal :
Banque Postale - Compte Courant
Tout va bien, il est content

Mais quand je saisis le même nom "Banque Postale - Compte Courant" dans mon formulaire F_Comptes_Plan, il me renvoie :
Erreur lors de l'écriture de l'enregistrement actif
Value too long in statement [UPDATE "T_Comptes_Plan" SET "NomCompte" = ? WHERE "ID_NumCompte" = ?]
Si j'enlève le tiret, ça roule, il est content mais pas moi !

Pouvez-vous m'expliquer cette différence de comportement ?

[jeanmimi]

Bonjour,
Rien qu'à lire le message, tu as la réponse : le texte que tu entres est plus long que la valeur attribuée au champ de la Table. Passe le champ à 200, et le problème devrait disparaitre.

Ajout : Ceci étant dit, ce n'est pas tout à fait comme ça qu'on insère des données qui sont répétitives comme le nom d'un compte dans un Journal de banque : dans la Table T_Comptes_Plan tu ne devrais entrer que l'ID du compte du Journal de banque et nom pas son nom (qui dépasse le 20 caractères).

[camil]

Désolé,
J'avais testé la largeur de mon formulaire avec des M dans mon nom de champ et je n'avais pas vérifié le nom que je voulais entrer
Merci et pardon pour cette question

[camil]

Je ne comprends pas ta remarque:
" Ceci étant dit, ce n'est pas tout à fait comme ça qu'on insère des données qui sont répétitives comme le nom d'un compte dans un Journal de banque"
Où est le risque (le problème), étant donné que ce journal est strictement lié à ce compte ?

Merci de ne pas poster plusieurs messages à la suite, si vous devez ajouter un complément d'information, le bouton "Editer" à la droite du message permet d'y remédier.

En attendant une prochaine réponse, vous pouvez participer également en répondant à d'autres questions sur notre forum.

[jeanmimi]

Ceci étant dit, ce n'est pas tout à fait comme ça qu'on insère des données qui sont répétitives comme le nom d'un compte dans un Journal de banque

On utilise plutôt les Zones de liste dans Base, ce qui évite les erreurs à la frappe des noms, dans ton cas, les noms des champs.
Il y a de nombreux exemples dans le forum avec une recherche sur "Base + Zone + Liste"

[Dude]

Où est le risque (le problème), étant donné que ce journal est strictement lié à ce compte ?

Il n'y a pas de risque sauf que tu auras des données redondantes.
Redondance qui fera grossir inutilement la taille de tes tables.
Tout cela va à l'encontre d'un modèle relationnel.

J'avais testé la largeur de mon formulaire avec des M dans mon nom de champ et je n'avais pas vérifié le nom que je voulais entrer

Ne confonds pas le stockage de la donnée et le formatage qu'elle peut avoir côté IHM.
Par exemple pour un numéro de sécurité sociale, il est inutile de stocker les espaces.
On utilise un contrôle de champ masqué qui permet d'avoir l'affichage voulu dans le formulaire.

Je suis novice, que ça soit dit

Tu as un post-it à lire d'urgence en tête de section :

[camil]

On utilise plutôt les Zones de liste dans Base, ce qui évite les erreurs à la frappe des noms, dans ton cas, les noms des champs.
Il y a de nombreux exemples dans le forum avec une recherche sur "Base + Zone + Liste"

C'est bien ce que je fait

[camil]

Il n'y a pas de risque sauf que tu auras des données redondantes.
Redondance qui fera grossir inutilement la taille de tes tables.
Tout cela va à l'encontre d'un modèle relationnel.

Je n'enregistre que les ID dans mes tables, pas l'intitulé des comptes ni des journaux

[jeanmimi]

Je n'enregistre que les ID dans mes tables, pas l'intitulé des comptes ni des journaux

Pourtant, ce n'est ce qui apparait ici.

[camil]

micmac râle parce que je n'avais pas donné suite à ce poste.
Je n'avais simplement pas reçu d'alerte pour la dernière réponse.

Je réponds donc :
Nom numéro de compte est une clef primaire (en VARCHAR) pour éviter les doublons.
Est-ce que ça peux poser un problème pour la suite ?

[Dredd]

Bonjour,

Nom numéro de compte est une clef primaire (en VARCHAR) pour éviter les doublons.
Est-ce que ça peux poser un problème pour la suite ?

Etant donné qu'il y a un risque que le numéro de compte soit identique entre deux banques, tu n'éviteras pas le doublon.
Et si tu te donnes la peine de Googler un peu, tu sauras qu'il est recommandé pour des questions de performances de ne pas utiliser de clé primaire en varchar

[camil]

Je note pour les varchar et je les abandonne.
Mes numéros étaient des numéros de plan comptable (pas de compte bancaire), donc uniques.

Merci pour les réponses