Question et aide pour création d'un formulaire
Résolu/Fermé
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
-
17 févr. 2013 à 19:04
tessel75 - 19 févr. 2013 à 22:26
tessel75 - 19 févr. 2013 à 22:26
A voir également:
- Question et aide pour création d'un formulaire
- Creation compte gmail - Guide
- Création organigramme - Guide
- Media creation tool - Télécharger - Systèmes d'exploitation
- Création compte google - Guide
- Logiciel création karaoké gratuit - Télécharger - DJ & Karaoké
13 réponses
Bonsoir,
Tu parles de 7 tables; la question n'est pas le nombre de tables, on a vu davantage, mais la requête source de ton futur formulaire.
Après le plus simple te le mieux pour toi, qui es débutant, sera d'utiliser l'assistant création. N'hésites surtout pas à utiliser cet outil, et les autres assistants qui sont assez pédagogiques.
Pour le moment, il me parait qu'il vaut mieux te concentrer sur la requête.
Bonne suite.
Tu parles de 7 tables; la question n'est pas le nombre de tables, on a vu davantage, mais la requête source de ton futur formulaire.
Après le plus simple te le mieux pour toi, qui es débutant, sera d'utiliser l'assistant création. N'hésites surtout pas à utiliser cet outil, et les autres assistants qui sont assez pédagogiques.
Pour le moment, il me parait qu'il vaut mieux te concentrer sur la requête.
Bonne suite.
Re-Bonsoir,
Tu ne me parais avoir lu ma remarque : "Pour le moment, il me parait qu'il vaut mieux te concentrer sur la requête."
Il ne sert à rien de te précipiter sur le formulaire, si le mode de recueil des données n'est pas au point. Le formulaire n'est qu'une façade qui rend l'entrée des données plus lisible et plus facile. Mais comme toutes les façades, ce qui importe est ce qui se passe derrière. Si tu as rencontré cet accident, c'est bien parce que l'organisation même de tes données est défaillante.
Pour ce que tu veux, il te faut non pas un seul formulaire, mais un formulaire et un sous-formulaire. Tu n'en es pas là. Mettre tout sur un seul formulaire ne peut pas convenir. Imagine un relevé bancaire où chaque ligne de compte reprendrait le nom de la banque, l'adresse, le N° de compte, le nom du conseiller, le montant du mouvement, etc; ce serait illisible, et c'est exactement ce que tu es en train de concocter.
En plus, je ne comprends pas Comment tu peux articuler tes tables "Journal", "Mouvements", "Paiement", et "Chèques". La vue que tu envoies présente des liaisons qui partent dans tous les sens, mais comme on ne peut pas bouger les représentation des tables, c'est impossibles de s'y retrouver ou d'essayer d'y mettre un peu d'ordre.
Tu ne peux pas avoir plusieurs journaux, or tu as une table "Journaux". Tu as une table "Paiement" mais avec un seul champ "LibellePaiement" et 2 champs de liaison, alors qu'il faudrait bien mieux que ce libellé figure sur la table "Mouvements". Idem pour les chèques, pourquoi ne pas intégrer dans la table "Mouvements" toutes les informations ayant trait à ces opérations alors qu'elles sont uniques pour chaque mouvement.
Je t'envoie ci-dessous un autre modèle relationnel que j'ai fait pour moi-même. S'il peut te servir?
Au passage, tu remarqueras que, aussi dans la table "ComptesDepots" que dans la table "ComptesTitres", je n'ai pas hésité à mettre 2 champs, [Entrees] et [Sorties], et même 2 fois 2 pour le "CompteDepot" parce que au moment du passage du Franc à l'€uro, j'étais obligé d'avoir la comptabilité dans les 2 monnaies.
http://cjoint.com/?3Brwkaai1Qe
Bonne suite
Tu ne me parais avoir lu ma remarque : "Pour le moment, il me parait qu'il vaut mieux te concentrer sur la requête."
Il ne sert à rien de te précipiter sur le formulaire, si le mode de recueil des données n'est pas au point. Le formulaire n'est qu'une façade qui rend l'entrée des données plus lisible et plus facile. Mais comme toutes les façades, ce qui importe est ce qui se passe derrière. Si tu as rencontré cet accident, c'est bien parce que l'organisation même de tes données est défaillante.
Pour ce que tu veux, il te faut non pas un seul formulaire, mais un formulaire et un sous-formulaire. Tu n'en es pas là. Mettre tout sur un seul formulaire ne peut pas convenir. Imagine un relevé bancaire où chaque ligne de compte reprendrait le nom de la banque, l'adresse, le N° de compte, le nom du conseiller, le montant du mouvement, etc; ce serait illisible, et c'est exactement ce que tu es en train de concocter.
En plus, je ne comprends pas Comment tu peux articuler tes tables "Journal", "Mouvements", "Paiement", et "Chèques". La vue que tu envoies présente des liaisons qui partent dans tous les sens, mais comme on ne peut pas bouger les représentation des tables, c'est impossibles de s'y retrouver ou d'essayer d'y mettre un peu d'ordre.
Tu ne peux pas avoir plusieurs journaux, or tu as une table "Journaux". Tu as une table "Paiement" mais avec un seul champ "LibellePaiement" et 2 champs de liaison, alors qu'il faudrait bien mieux que ce libellé figure sur la table "Mouvements". Idem pour les chèques, pourquoi ne pas intégrer dans la table "Mouvements" toutes les informations ayant trait à ces opérations alors qu'elles sont uniques pour chaque mouvement.
Je t'envoie ci-dessous un autre modèle relationnel que j'ai fait pour moi-même. S'il peut te servir?
Au passage, tu remarqueras que, aussi dans la table "ComptesDepots" que dans la table "ComptesTitres", je n'ai pas hésité à mettre 2 champs, [Entrees] et [Sorties], et même 2 fois 2 pour le "CompteDepot" parce que au moment du passage du Franc à l'€uro, j'étais obligé d'avoir la comptabilité dans les 2 monnaies.
http://cjoint.com/?3Brwkaai1Qe
Bonne suite
Bonjour,
1) Pour rassembler plusieurs tables il faut toujours une requête. Mais le SQL n'est pas du tout indispensable, il suffit de se mettre en "mode Création" qui est très intuitif, relier les tables et sélectionner les champs désirés.
2) Tu n'as pas regardé le plan de modèle relationnel que j'ai envoyé; c'est dommage parce que je le crois pourtant assez instructif, et en particulier tu verras que je n'ai pas hésité à inclure pour les 2 tables [ComptesDepots] et [ComptesTitres], 2 champs pour les entrées et les sorties, ce qui rends les choses bien plus claires sans que ce soit plus compliqué. Dans tous les cas la base présentée comme cela est extrêmement simple avec tous les items que j'avais pu dire auparavant.
1) Pour rassembler plusieurs tables il faut toujours une requête. Mais le SQL n'est pas du tout indispensable, il suffit de se mettre en "mode Création" qui est très intuitif, relier les tables et sélectionner les champs désirés.
2) Tu n'as pas regardé le plan de modèle relationnel que j'ai envoyé; c'est dommage parce que je le crois pourtant assez instructif, et en particulier tu verras que je n'ai pas hésité à inclure pour les 2 tables [ComptesDepots] et [ComptesTitres], 2 champs pour les entrées et les sorties, ce qui rends les choses bien plus claires sans que ce soit plus compliqué. Dans tous les cas la base présentée comme cela est extrêmement simple avec tous les items que j'avais pu dire auparavant.
Bonsoir,
Je ne peux pas répondre à la dernière question car il faudrait avoir la base sous les yeux. Et en fait, il est vrai que ces messages sont les plus empoisonnants parce qu'ils sont causés la plupart du temps par une défaillance dans l'enregistrement de données la quelle résulte d'un défaut dans la construction de la base elle-même, ou bien par le non-respect de contraintes mises au moment de la construction des tables; ce qui fait qu'il faut souvent chercher longtemps la raison et l'origine du refus de l'enregistrement.
Pour ce qui est de l'exemple que j'ai envoyé, les tables ne sont pas "trop lourde" à la condition de savoir précisément ce qu'on va y enregistrer. J'ai un champ "Commentaires" qui permet d'enregistrer n'importe quel texte correspondant à toutes informations que souhaite enregistrer l'utilisateur, en ce sens il remplace avantageusement ton "sousJournal" parce qu'il m'évite d'avoir une table supplémentaire tout en ayant les mêmes possibilités d'enregistrer les types d'information. Alors à choisir entre un champ de ce type et une table supplémentaire, je crois préférable un champ comme cela. Après c'est comme tout, question de préférence.
Cordialement.
Je ne peux pas répondre à la dernière question car il faudrait avoir la base sous les yeux. Et en fait, il est vrai que ces messages sont les plus empoisonnants parce qu'ils sont causés la plupart du temps par une défaillance dans l'enregistrement de données la quelle résulte d'un défaut dans la construction de la base elle-même, ou bien par le non-respect de contraintes mises au moment de la construction des tables; ce qui fait qu'il faut souvent chercher longtemps la raison et l'origine du refus de l'enregistrement.
Pour ce qui est de l'exemple que j'ai envoyé, les tables ne sont pas "trop lourde" à la condition de savoir précisément ce qu'on va y enregistrer. J'ai un champ "Commentaires" qui permet d'enregistrer n'importe quel texte correspondant à toutes informations que souhaite enregistrer l'utilisateur, en ce sens il remplace avantageusement ton "sousJournal" parce qu'il m'évite d'avoir une table supplémentaire tout en ayant les mêmes possibilités d'enregistrer les types d'information. Alors à choisir entre un champ de ce type et une table supplémentaire, je crois préférable un champ comme cela. Après c'est comme tout, question de préférence.
Cordialement.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
17 févr. 2013 à 20:53
17 févr. 2013 à 20:53
Bonsoir tessel75,
pour information j'utilise l'assistant de formulaire.
Voici le modèle relationnel : http://d35.e-loader.net/QpBt9hkxRQ.jpg
Sur ce formulaire je voudrais mettre mes tables "Journal", "SousJournal", "Mouvements", "Paiement", "BanqueAssurance", "Cheques", "Conseiller", mais si sur le formulaire, je modifie par exemple que la table "paiement" et la table "mouvements", je ne veux qu'il ne ce passe rien sur les autres tables aussi.
Mais j'ai essayé avec l'assistant formulaire, mais je n'ai pas su l'organiser car du coup il ma ouvert 7 formulaires différents (un formulaire par table), donc peut être que j'ai mal géré les clés primaires ou j'ai commis d'autres erreur.
Donc, si vous pourriez m'aidez ou m'expliquer mes erreurs que j'aurais commis, je vous remercierai beaucoup.
Merci pour votre réponse.
Bonne soirée.
Cordialement Jiben59.
pour information j'utilise l'assistant de formulaire.
Voici le modèle relationnel : http://d35.e-loader.net/QpBt9hkxRQ.jpg
Sur ce formulaire je voudrais mettre mes tables "Journal", "SousJournal", "Mouvements", "Paiement", "BanqueAssurance", "Cheques", "Conseiller", mais si sur le formulaire, je modifie par exemple que la table "paiement" et la table "mouvements", je ne veux qu'il ne ce passe rien sur les autres tables aussi.
Mais j'ai essayé avec l'assistant formulaire, mais je n'ai pas su l'organiser car du coup il ma ouvert 7 formulaires différents (un formulaire par table), donc peut être que j'ai mal géré les clés primaires ou j'ai commis d'autres erreur.
Donc, si vous pourriez m'aidez ou m'expliquer mes erreurs que j'aurais commis, je vous remercierai beaucoup.
Merci pour votre réponse.
Bonne soirée.
Cordialement Jiben59.
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
18 févr. 2013 à 00:52
18 févr. 2013 à 00:52
Bonsoir,
je voudrais bien mettre mes chèques à l'intérieur des mes mouvements mais sa fait un champs pour les chèques tirés, un champs pour les chèques encaissés, la date d'encaissement du chèque, donc sa risque d'agrandir la table encore aussi ?
Je crois aussi que je rencontre un problème avec le champs CodeSousJournal dans la table "Mouvements", car quand je veux associé un CodeSousJournal avec un mouvements j'ai le message suivants : http://d7.e-loader.net/THkfoFDGJP.jpg
J'ai bien vu ta remarque mais quand vous dites requêtes, vous parlez du SQL aussi ?
Merci de vos réponses.
Cordialement Jiben59.
je voudrais bien mettre mes chèques à l'intérieur des mes mouvements mais sa fait un champs pour les chèques tirés, un champs pour les chèques encaissés, la date d'encaissement du chèque, donc sa risque d'agrandir la table encore aussi ?
Je crois aussi que je rencontre un problème avec le champs CodeSousJournal dans la table "Mouvements", car quand je veux associé un CodeSousJournal avec un mouvements j'ai le message suivants : http://d7.e-loader.net/THkfoFDGJP.jpg
J'ai bien vu ta remarque mais quand vous dites requêtes, vous parlez du SQL aussi ?
Merci de vos réponses.
Cordialement Jiben59.
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
18 févr. 2013 à 11:57
18 févr. 2013 à 11:57
Bonjour,
Oui, c'est vrai qui a le mode création qui permet aussi d'aller plus vite car l'on a pas le besoin de frapper touts les champs qu'il faut.
Si, j'ai regardé votre modèle relationnel, mais sa ferait beaucoup dans une table aussi ? (Rajout des champs : chèque, chèque tiré, chèque encaissé, date du chèque encaissé, débit, crédit)
Puis, j'avais vu que vous n'aviez pas créée une table titulaire mais que vous l'aviez mit dans la table "Banque", donc surement que je ferrais de même.
Puis, quand l'on fait des champs, sa ne fait rien si l'on ne mets pas le nom de la table derrière ? Car vous c'est plus léger dans les tables et moi par contre c'est beaucoup plus lourd car j'ai Code SousJournal, NomSousJournal.
En revanche, ma table "CodeSousJournal" est bien reliée à la table "Mouvements" donc je ne vois pas pourquoi ce message d'erreur :s
Merci pour vos réponse,
Cordialement Jiben59.
Oui, c'est vrai qui a le mode création qui permet aussi d'aller plus vite car l'on a pas le besoin de frapper touts les champs qu'il faut.
Si, j'ai regardé votre modèle relationnel, mais sa ferait beaucoup dans une table aussi ? (Rajout des champs : chèque, chèque tiré, chèque encaissé, date du chèque encaissé, débit, crédit)
Puis, j'avais vu que vous n'aviez pas créée une table titulaire mais que vous l'aviez mit dans la table "Banque", donc surement que je ferrais de même.
Puis, quand l'on fait des champs, sa ne fait rien si l'on ne mets pas le nom de la table derrière ? Car vous c'est plus léger dans les tables et moi par contre c'est beaucoup plus lourd car j'ai Code SousJournal, NomSousJournal.
En revanche, ma table "CodeSousJournal" est bien reliée à la table "Mouvements" donc je ne vois pas pourquoi ce message d'erreur :s
Merci pour vos réponse,
Cordialement Jiben59.
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
18 févr. 2013 à 23:04
18 févr. 2013 à 23:04
Bonsoir,
je crois que je rencontre ce problème car j'ai "code journal" dans la table SousJournal, donc peut être que cela empêche de relier la table car elle est déjà reliée ?
La table SousJournal : http://d9.e-loader.net/8clL7uc33q.jpg
J'ai créer cette table pour pouvoir faire des requêtes sous formulaire par la suite pour assurer le montant de dépense par tels branche, car j'aime bien avoir de bon résultats comme une comptabilité analytique si vous voyait de quoi je parle.
Le modèle relationnel (je n'ai pas encore modifié la table mouvement vus que le problème n'est pas réglé) : http://d6.e-loader.net/gp9TYRTdgR.jpg
Vous entendez quoi par "contraintes" si vous plaît ?
Je vous remercie de me répondre à chaque fois et m'apporter votre aide.
Bonne soirée,
cordialement.
je crois que je rencontre ce problème car j'ai "code journal" dans la table SousJournal, donc peut être que cela empêche de relier la table car elle est déjà reliée ?
La table SousJournal : http://d9.e-loader.net/8clL7uc33q.jpg
J'ai créer cette table pour pouvoir faire des requêtes sous formulaire par la suite pour assurer le montant de dépense par tels branche, car j'aime bien avoir de bon résultats comme une comptabilité analytique si vous voyait de quoi je parle.
Le modèle relationnel (je n'ai pas encore modifié la table mouvement vus que le problème n'est pas réglé) : http://d6.e-loader.net/gp9TYRTdgR.jpg
Vous entendez quoi par "contraintes" si vous plaît ?
Je vous remercie de me répondre à chaque fois et m'apporter votre aide.
Bonne soirée,
cordialement.
Re
Pour reprendre la question à l'origine, tu demandais de l'aide pour créer une base pouvant servir à la gestion d'un (de) compte(s) bancaire(s). Je peux pas faire mieux que celui que j'ai posté puisque c'est le modèle de la base que je me suis faite et que j'utilise depuis une douzaine d'années.
Maintenant la question d'un "code" pour mettre en série les différentes opérations, c'est une excellente idée mais il n'est pas nécessaire pour autant d'avoir une table rien que pour cela, un simple champ suffit avec une liste déroulante non limitée qui reprend les différentes valeurs précédemment entrées et la possibilité d'en ajouter d'autres à mesure que le besoin s'en fait sentir. De la sorte il y a toujours possibilité de regrouper les opérations par catégorie d'entrées et de sorties. C'est le principe même de table "SousJournal" que je conteste.
A propos des "contraintes" : je veux parler des propriétés, des index, des clés, etc.., qu'on pose au moment de la création des tables en croyant bien faire, et qui gênent par la suite parce qu'elles imposent d'entrer des données alors que c'est inutile à ce moment, ou bien parce que les opérations qu'on est amené à vouloir faire se révèlent incompatibles avec ces propriétés,
Bonne nuit.
Pour reprendre la question à l'origine, tu demandais de l'aide pour créer une base pouvant servir à la gestion d'un (de) compte(s) bancaire(s). Je peux pas faire mieux que celui que j'ai posté puisque c'est le modèle de la base que je me suis faite et que j'utilise depuis une douzaine d'années.
Maintenant la question d'un "code" pour mettre en série les différentes opérations, c'est une excellente idée mais il n'est pas nécessaire pour autant d'avoir une table rien que pour cela, un simple champ suffit avec une liste déroulante non limitée qui reprend les différentes valeurs précédemment entrées et la possibilité d'en ajouter d'autres à mesure que le besoin s'en fait sentir. De la sorte il y a toujours possibilité de regrouper les opérations par catégorie d'entrées et de sorties. C'est le principe même de table "SousJournal" que je conteste.
A propos des "contraintes" : je veux parler des propriétés, des index, des clés, etc.., qu'on pose au moment de la création des tables en croyant bien faire, et qui gênent par la suite parce qu'elles imposent d'entrer des données alors que c'est inutile à ce moment, ou bien parce que les opérations qu'on est amené à vouloir faire se révèlent incompatibles avec ces propriétés,
Bonne nuit.
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
19 févr. 2013 à 10:02
19 févr. 2013 à 10:02
Bonjour tessel75,
j'ai décidé cette table car je numérise mes documents aussi, donc pour l'assurance j'ai mon tableau d'assurance, l'emprunt mon tableau de remboursement..
Je pense que je vais créer une table quelconque pour faire importer ses document sans les relier alors ;)
Merci de me définir les contraintes car tout le monde n'a pas le même langage, donc sa permet de ce comprendre dans les meilleures façon.
En espérant, que ce problème ce ressoudera.
Merci de votre aide.
Bonne journée à vous.
Cordialement Jiben59.
j'ai décidé cette table car je numérise mes documents aussi, donc pour l'assurance j'ai mon tableau d'assurance, l'emprunt mon tableau de remboursement..
Je pense que je vais créer une table quelconque pour faire importer ses document sans les relier alors ;)
Merci de me définir les contraintes car tout le monde n'a pas le même langage, donc sa permet de ce comprendre dans les meilleures façon.
En espérant, que ce problème ce ressoudera.
Merci de votre aide.
Bonne journée à vous.
Cordialement Jiben59.
Re-Bonsoir,
La question n'est pas de rejeter complètement les tables adjacentes; la question est de savoir pourquoi on les fait, et qu'est-ce qu'on en fait. Dans tous les cas il doit s'agir d'alléger le plus possible a base dans son entier.
C'est à dire que si on a l'intention de pouvoir ajouter un "petit" commentaire à la majorité des enregistrements alors il vaut mieux avoir un champ "Commentaires" dans la table elle-même puisqu'il sera presque toujours utilisé, et toute autre solution ne ferait qu'alourdir puisqu'il sera nécessaire de créer des champs de liens entre les tables. Par contre, si l'intention est d'avoir soit un commentaire soit un autre élément tous les 10 ou 15 enregistrements et que cet élément est prévu être d'un certain volume, alors il vaut mieux prévoir une table adjacente liée pour la simple raison qu'elle se remplira 10 fois moins vite que la table principale, et qu'en plus sans cette table adjacente il serait nécessaire d'avoir un champ assez gros pour recevoir l'information sans pour autant l'utiliser davantage. Tout cela n'est qu'une question de réflexion.
Par ailleurs, tu dis vouloir numériser les documents en question. Dans ce cas il faut savoir que toutes les images quelque soit leur nature prennent énormément de place, aussi ne faut-il surtout pas les intégrer directement dans la base mais dans un dossier à part et les lier à l'enregistrement voulu par un lien hypertexte. Il existe un format "Lien Hypertexte" ou un format "objet OLE" pour les champs des tables, c'est bien pour s'en servir; ainsi il suffit de cliquer sur le lien pour ouvrir à volonté le document.
Bonne suite.
La question n'est pas de rejeter complètement les tables adjacentes; la question est de savoir pourquoi on les fait, et qu'est-ce qu'on en fait. Dans tous les cas il doit s'agir d'alléger le plus possible a base dans son entier.
C'est à dire que si on a l'intention de pouvoir ajouter un "petit" commentaire à la majorité des enregistrements alors il vaut mieux avoir un champ "Commentaires" dans la table elle-même puisqu'il sera presque toujours utilisé, et toute autre solution ne ferait qu'alourdir puisqu'il sera nécessaire de créer des champs de liens entre les tables. Par contre, si l'intention est d'avoir soit un commentaire soit un autre élément tous les 10 ou 15 enregistrements et que cet élément est prévu être d'un certain volume, alors il vaut mieux prévoir une table adjacente liée pour la simple raison qu'elle se remplira 10 fois moins vite que la table principale, et qu'en plus sans cette table adjacente il serait nécessaire d'avoir un champ assez gros pour recevoir l'information sans pour autant l'utiliser davantage. Tout cela n'est qu'une question de réflexion.
Par ailleurs, tu dis vouloir numériser les documents en question. Dans ce cas il faut savoir que toutes les images quelque soit leur nature prennent énormément de place, aussi ne faut-il surtout pas les intégrer directement dans la base mais dans un dossier à part et les lier à l'enregistrement voulu par un lien hypertexte. Il existe un format "Lien Hypertexte" ou un format "objet OLE" pour les champs des tables, c'est bien pour s'en servir; ainsi il suffit de cliquer sur le lien pour ouvrir à volonté le document.
Bonne suite.
Jiben59
Messages postés
120
Date d'inscription
mardi 25 septembre 2012
Statut
Membre
Dernière intervention
2 janvier 2016
1
19 févr. 2013 à 22:06
19 févr. 2013 à 22:06
Bonsoir,
Je viens de trouver le problème sa venez du réglage de la liste déroulante que j'ai fait dans la table mouvement pour le champs CodeSsJrnl.
Mais, je me pose toujours la question pour la table chèque car dans celle ci il y a le code du paiement c'est à dire "CHQ", le numéro du chèque, l'intitulé du chèque (exemple: Carburant), la date lorsque le chèque à été effectué, la date du chèque lors il a été encaissé, le texte logique pour savoir si le chèque à été tiré ou encaissé.
Je rajoute tous ces champs dans mouvements ou je les laisse dans la table chèque ? Car quand je vais faire l'état de ma table mouvement il aura jamais assez de place aussi. Un sachant que j'ai déjà crée un formulaire pour savoir lesquelles des chèques n'est pas encore tiré.
Votre aide m'aiderez svp, car moi je pencherai de le laisser dans la table chèque.
Puis je cherche une idée pour différencier mes chèques et les chèques je reçois par moments, et une astuce pour les chèques annulé comme lorsque l'on fait un acompte.
Merci de la précision pour les images, et de l'astuce des hypertextes qui me devrait être très utiles.
Bonne soirée et encore merci de votre aide.
Cordialement.
Je viens de trouver le problème sa venez du réglage de la liste déroulante que j'ai fait dans la table mouvement pour le champs CodeSsJrnl.
Mais, je me pose toujours la question pour la table chèque car dans celle ci il y a le code du paiement c'est à dire "CHQ", le numéro du chèque, l'intitulé du chèque (exemple: Carburant), la date lorsque le chèque à été effectué, la date du chèque lors il a été encaissé, le texte logique pour savoir si le chèque à été tiré ou encaissé.
Je rajoute tous ces champs dans mouvements ou je les laisse dans la table chèque ? Car quand je vais faire l'état de ma table mouvement il aura jamais assez de place aussi. Un sachant que j'ai déjà crée un formulaire pour savoir lesquelles des chèques n'est pas encore tiré.
Votre aide m'aiderez svp, car moi je pencherai de le laisser dans la table chèque.
Puis je cherche une idée pour différencier mes chèques et les chèques je reçois par moments, et une astuce pour les chèques annulé comme lorsque l'on fait un acompte.
Merci de la précision pour les images, et de l'astuce des hypertextes qui me devrait être très utiles.
Bonne soirée et encore merci de votre aide.
Cordialement.
Re_,
Pour ce qui est des chèques, je ne peux pas répondre à ta place. La seule question qui importe est celle de la cohérence, mais il me semble que tout ce qui concerne les chèques a sa place dans la table "Chèques" plus qu'ailleurs.
Par ailleurs, la question de la place, dans un formulaire ou un état, est une non-question parce qu'on se débrouille toujours pour caser ce doit y être casé.
J'ai trouvé ce lien pour t'aider à bien réfléchir à ce que tu voulais faire, et à la manière de concevoir une base de données. ça me parait indispensable de bien connaitre et bien comprendre.
http://www.commentcamarche.net/contents/s/merise/
Bonne nuit.
Pour ce qui est des chèques, je ne peux pas répondre à ta place. La seule question qui importe est celle de la cohérence, mais il me semble que tout ce qui concerne les chèques a sa place dans la table "Chèques" plus qu'ailleurs.
Par ailleurs, la question de la place, dans un formulaire ou un état, est une non-question parce qu'on se débrouille toujours pour caser ce doit y être casé.
J'ai trouvé ce lien pour t'aider à bien réfléchir à ce que tu voulais faire, et à la manière de concevoir une base de données. ça me parait indispensable de bien connaitre et bien comprendre.
http://www.commentcamarche.net/contents/s/merise/
Bonne nuit.
