Comment créer une table de sauvegarde après impression d'un état.
5 réponses
Pierre
Bonjour,
J'ai créer un formulaire "F_Saisir commande" basé sur une requete
R_Commande (fichiers T_Client et T_Commande)
sur ce formulaire un sous-formulaire "F_Contenu commande" basé sur une
requete R_Contenucommande (Fichier T_contenucommande et T_Nomenclature)
Apres saisie d'une commande dans le formulaire et du contenu de cette
dernière dans le sous-formulaire, j'ai placé en pied de formulaire un bouton
de commande imprimer, qui renvoie vers un état pour effectuer l'impression
du bon de livraison.(==> commande terminée et livrée avec facture
récapitulative des différentes livraison en fin de mois)
Je souhaiterai après impression, enregistrer le contenu des champs provenant
du formulaire dans une table T_Commande(mois&année) exemple.
T_Commande122004 et les champs du sous-formulaire dans une table
T_Contenucommande(mois&année)
Ces 2 nouvelles tables devant se créer automatique à chaque changement de
mois.
Ceci me permettant de ne plus avoir d'anciennes commandes mélangées avec des
commandes en cours et
également d'imprimer les factures fin de mois sur base de ces 2 tables. ou
éventuellemnt un duplicata du bon de commande.
Pouvez vous me dire si access permet ce genre de solution et si oui comment
faut-il procéder.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel BERTRAND
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Bonjour
creer des tables par mois SURTOUT PAS !
Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit...
donc il faut baser les états sur des requetes
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Pierre
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même
table, je voudrai quand même pour des raisons de volume et de clarté dans
la gestion de mes tables faire des sauvegardes en fin de mois
De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les
commandes terminées .
Donc, ma question reste posée
Merci pour votre aide
Pierre
"Michel BERTRAND" <mbfac.enlever@oter.free.fr> a écrit dans le message de
news: cp90se$iij$1@news.tiscali.fr...
Bonjour
creer des tables par mois SURTOUT PAS !
Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit...
donc il faut baser les états sur des requetes
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Daniel Carollo
Bonjour Pierre!
Il y a deux facons de voir les tables: d'un point de vue programmeur, et d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance, sauf quand ce volume commence a avoir un impact serieux sur la performance. Pour ce qui est de la "clarte" des gestions, les requetes sont faites justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue. L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables. (Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du programmeur que de lui donner une interface qui permet de voir le contenu des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un processus irreversible de mise a jour des donnees tous les mois. Il est essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base sans la periode que l'on peut se permettre de recommencer. Pour la plupart des gens, cela signifie une sauvegarde journaliere (encore que peu d'entre-eux ont reflechi au consequences de devoir recapturer les donnees de la journee d'hier).
Bonne reflexion,
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Pierre" wrote in message news:%
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même
table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Bonjour Pierre!
Il y a deux facons de voir les tables: d'un point de vue programmeur, et
d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance,
sauf quand ce volume commence a avoir un impact serieux sur la performance.
Pour ce qui est de la "clarte" des gestions, les requetes sont faites
justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue.
L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables.
(Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du
programmeur que de lui donner une interface qui permet de voir le contenu
des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent
au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un
processus irreversible de mise a jour des donnees tous les mois. Il est
essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base
sans la periode que l'on peut se permettre de recommencer. Pour la plupart
des gens, cela signifie une sauvegarde journaliere (encore que peu
d'entre-eux ont reflechi au consequences de devoir recapturer les donnees de
la journee d'hier).
Bonne reflexion,
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Pierre" <pierre.piqueray@skynet.be> wrote in message
news:%23o4aFwc3EHA.2600@TK2MSFTNGP09.phx.gbl...
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une
même
table, je voudrai quand même pour des raisons de volume et de clarté dans
la gestion de mes tables faire des sauvegardes en fin de mois
De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les
commandes terminées .
Donc, ma question reste posée
Merci pour votre aide
Pierre
"Michel BERTRAND" <mbfac.enlever@oter.free.fr> a écrit dans le message de
news: cp90se$iij$1@news.tiscali.fr...
Bonjour
creer des tables par mois SURTOUT PAS !
Il faut tout garder dans la meme table cela permet des stats plus
faciles
comparatif par années/mois par produit...
donc il faut baser les états sur des requetes
Il y a deux facons de voir les tables: d'un point de vue programmeur, et d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance, sauf quand ce volume commence a avoir un impact serieux sur la performance. Pour ce qui est de la "clarte" des gestions, les requetes sont faites justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue. L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables. (Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du programmeur que de lui donner une interface qui permet de voir le contenu des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un processus irreversible de mise a jour des donnees tous les mois. Il est essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base sans la periode que l'on peut se permettre de recommencer. Pour la plupart des gens, cela signifie une sauvegarde journaliere (encore que peu d'entre-eux ont reflechi au consequences de devoir recapturer les donnees de la journee d'hier).
Bonne reflexion,
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Pierre" wrote in message news:%
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même
table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Pierre
Bonjour,
Je pense que vos conseils sont très judicieux et je vous en remercie. J'ai donc ajouter un champs de type OUI/NON (imprimer et terminer) a ma table Commande
Toutefois, Je souhaiterai en fin d'année, nettoyer les enregistrements commande terminée (Champs OUI/NON valeur = OUI) de l'année écoulée et les sauvegarder dans une nouvelle table(qui peut-etre même externe au programme), ainsi je n'aurai pas un backup comportant des commandes en cours mais uniquement le résultat de mon année passé.et de ce fait une table moins lourde à gérer.
Encore merci pour toutes vos réponses
Pierre
Merci
"Daniel Carollo" a écrit dans le message de news:
Bonjour Pierre!
Il y a deux facons de voir les tables: d'un point de vue programmeur, et d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance, sauf quand ce volume commence a avoir un impact serieux sur la performance. Pour ce qui est de la "clarte" des gestions, les requetes sont faites justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue. L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables. (Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du programmeur que de lui donner une interface qui permet de voir le contenu des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un processus irreversible de mise a jour des donnees tous les mois. Il est essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base sans la periode que l'on peut se permettre de recommencer. Pour la plupart des gens, cela signifie une sauvegarde journaliere (encore que peu d'entre-eux ont reflechi au consequences de devoir recapturer les donnees de la journee d'hier).
Bonne reflexion,
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Pierre" wrote in message news:%
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même
table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Bonjour,
Je pense que vos conseils sont très judicieux et je vous en remercie.
J'ai donc ajouter un champs de type OUI/NON (imprimer et terminer) a ma
table Commande
Toutefois, Je souhaiterai en fin d'année, nettoyer les enregistrements
commande terminée (Champs OUI/NON valeur = OUI) de l'année écoulée et les
sauvegarder dans une nouvelle table(qui peut-etre même externe au
programme), ainsi je n'aurai pas un backup comportant des commandes en
cours mais uniquement le résultat de mon année passé.et de ce fait une table
moins lourde à gérer.
Encore merci pour toutes vos réponses
Pierre
Merci
"Daniel Carollo" <danielc@NO_SPAM_PLEASE.computing-tech.com> a écrit dans le
message de news: OKQGBgd3EHA.3452@TK2MSFTNGP14.phx.gbl...
Bonjour Pierre!
Il y a deux facons de voir les tables: d'un point de vue programmeur, et
d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance,
sauf quand ce volume commence a avoir un impact serieux sur la
performance.
Pour ce qui est de la "clarte" des gestions, les requetes sont faites
justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue.
L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables.
(Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du
programmeur que de lui donner une interface qui permet de voir le contenu
des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent
au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un
processus irreversible de mise a jour des donnees tous les mois. Il est
essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base
sans la periode que l'on peut se permettre de recommencer. Pour la plupart
des gens, cela signifie une sauvegarde journaliere (encore que peu
d'entre-eux ont reflechi au consequences de devoir recapturer les donnees
de
la journee d'hier).
Bonne reflexion,
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Pierre" <pierre.piqueray@skynet.be> wrote in message
news:%23o4aFwc3EHA.2600@TK2MSFTNGP09.phx.gbl...
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une
même
table, je voudrai quand même pour des raisons de volume et de clarté
dans
la gestion de mes tables faire des sauvegardes en fin de mois
De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les
commandes terminées .
Donc, ma question reste posée
Merci pour votre aide
Pierre
"Michel BERTRAND" <mbfac.enlever@oter.free.fr> a écrit dans le message de
news: cp90se$iij$1@news.tiscali.fr...
Bonjour
creer des tables par mois SURTOUT PAS !
Il faut tout garder dans la meme table cela permet des stats plus
faciles
comparatif par années/mois par produit...
donc il faut baser les états sur des requetes
Je pense que vos conseils sont très judicieux et je vous en remercie. J'ai donc ajouter un champs de type OUI/NON (imprimer et terminer) a ma table Commande
Toutefois, Je souhaiterai en fin d'année, nettoyer les enregistrements commande terminée (Champs OUI/NON valeur = OUI) de l'année écoulée et les sauvegarder dans une nouvelle table(qui peut-etre même externe au programme), ainsi je n'aurai pas un backup comportant des commandes en cours mais uniquement le résultat de mon année passé.et de ce fait une table moins lourde à gérer.
Encore merci pour toutes vos réponses
Pierre
Merci
"Daniel Carollo" a écrit dans le message de news:
Bonjour Pierre!
Il y a deux facons de voir les tables: d'un point de vue programmeur, et d'un point de vue utilisateur.
Du point de vue programmeur, le volume d'une table n'a pas d'importance, sauf quand ce volume commence a avoir un impact serieux sur la performance. Pour ce qui est de la "clarte" des gestions, les requetes sont faites justement pour isoler un ensemble de donnees de la foison eventuelle.
Du point de vue utilisateur, il n'y a en fait pas de point de vue. L'utilisateur n'a pas a mettre ses sales petits doigts dans les tables. (Coup de marteau sur les doigts de l'utilisateur ici). C'est le travail du programmeur que de lui donner une interface qui permet de voir le contenu des tables d'une maniere qui soit adaptee au "volume et clarté" qui seyent au niveau de l'utilisateur.
Michel vous a donne un conseil essentiel, suivez le jusqu'au bout.
Des sauvegardes mensuelles sont, a mon avis, inutiles; sauf s'il y a un processus irreversible de mise a jour des donnees tous les mois. Il est essentiel d'avoir un cycle de sauvegarde qui permette de recuperer la base sans la periode que l'on peut se permettre de recommencer. Pour la plupart des gens, cela signifie une sauvegarde journaliere (encore que peu d'entre-eux ont reflechi au consequences de devoir recapturer les donnees de la journee d'hier).
Bonne reflexion,
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Pierre" wrote in message news:%
Bonjour, merci de prendre du temps pour m'aider.
D'accord pour les stats, mais votre réponse ne ressout pas mon problème
Car même si je conserve toutes mes données de l'année en cours dans une même
table, je voudrai quand même pour des raisons de volume et de clarté dans la gestion de mes tables faire des sauvegardes en fin de mois De cette façon j'aurai un nouveau jeu de table qui ne contiendrai que les commandes terminées .
Donc, ma question reste posée
Merci pour votre aide Pierre
"Michel BERTRAND" a écrit dans le message de news: cp90se$iij$
Bonjour
creer des tables par mois SURTOUT PAS ! Il faut tout garder dans la meme table cela permet des stats plus faciles
comparatif par années/mois par produit... donc il faut baser les états sur des requetes
Cordialement
Michel BERTRAND
Michel BERTRAND
Bonjour
... comportant des commandes en
cours mais uniquement le résultat de mon année passé.et de ce fait une table
moins lourde à gérer.
Elle fait quelle taille la base au bout d'un an ?...50Mo ?
Cordialement Michel BERTRAND
Bonjour
... comportant des commandes en
cours mais uniquement le résultat de mon année passé.et de ce fait une
table
moins lourde à gérer.
Elle fait quelle taille la base au bout d'un an ?...50Mo ?
