[WD8] Tables fichiers ou mémoire avec saisie en cascade
2 réponses
Phil
Bonjour,
Plusieurs méthodes sont possible pour faire la saisie de chacune des lignes
des ventes dans une facture. À première vue, la saisie des données
directement depuis une table fichier ou mémoire avec entrée en cascade
semble toute indiqué pour cela.
De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up, ou
encore se positionne sur une ligne et presse la touche Delete on peut gérer
tout ça facilement j'imagine. Et comme l'usager est directement dans la
table, il peut facilement aller changer les quantités commandées ou vendues,
ou encore le prix unitaire si on lui en donne la permission.
Mais j'hésite et vous demande votre avis parce que le Manuel de
programmation de PCS mentionne à la section 12.4 de la page 326 « Les tables
fichiers sont essentiellement utilisées pour visualiser les données. Pour
saisir des données, il est préférable de le faire dans des champs de
saisie. ».
Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de la
page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en
saisie. »
Et pourtant la fonction de saisie en cascade existe et semble bien
fonctionner.
Pour ceux qui utilisent des saisies de lignes de commandes ou de factures
dans leurs applications, quelle méthode préférez-vous et pourquoi?
Quels sont les inconvénients véritables à utiliser une saisie en cascade
dans une table ? PCS le déconseille mais ne dit pas pourquoi.
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
Romuald.besset
Phil wrote:
Bonjour,
Plusieurs méthodes sont possible pour faire la saisie de chacune des lignes des ventes dans une facture. À première vue, la saisie des données directement depuis une table fichier ou mémoire avec entrée en cascade semble toute indiqué pour cela.
De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up, ou encore se positionne sur une ligne et presse la touche Delete on peut gérer tout ça facilement j'imagine. Et comme l'usager est directement dans la table, il peut facilement aller changer les quantités commandées ou vendues, ou encore le prix unitaire si on lui en donne la permission.
Mais j'hésite et vous demande votre avis parce que le Manuel de programmation de PCS mentionne à la section 12.4 de la page 326 « Les tables fichiers sont essentiellement utilisées pour visualiser les données. Pour saisir des données, il est préférable de le faire dans des champs de saisie. ».
Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de la page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en saisie. »
Et pourtant la fonction de saisie en cascade existe et semble bien fonctionner.
Pour ceux qui utilisent des saisies de lignes de commandes ou de factures dans leurs applications, quelle méthode préférez-vous et pourquoi?
Quels sont les inconvénients véritables à utiliser une saisie en cascade dans une table ? PCS le déconseille mais ne dit pas pourquoi.
Réal Phil
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur. Néanmoins, nous avons effectivement abandonné systématiquement la saisie dans les table... et encore moins dans les tables fichiers. En effet, outre le problème du pointeur d'enregistrement (avec le scrolling) se pose le problème des contrôles et de la validation des saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui doit être débranché pendant la saisie. la modification de chaque colonne suppose-t elle celle de l'enregistrement ? Qui des contrôles dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre table_et_fiche ou l'utilisateur navigue entre les deux parties de la fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier une ligne. Evidement un jeu sur l'activation des groupes de champs permet d'avoir une validation de la fiche indépendant de celle de la fenêtre. Inutile alors de préciser que les contrôles nécesaires sont tous à portée de programmation... Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans un table est utilisée : - Une unique colonne en saisie (sélecteur/numérique) - Table fichier basée sur un temporaire sans contrainte d'intégrité/blocage - ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans les projets d'envergure point n'est nécessaire de vouloir s'ajouter des problèmes potentiels, il y en a généralement assez à résoudre. Parfois 'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de perdre du temps sur la mise au point de règles d'interface avec pourquoi pas des fenêtres modèles (RAD et autre). Ainsi en augmentant l'uniformité de fonctionnement des modules de votre projet, vous diminuerez les efforts de formation/support à produire ce qui est un investissement non négligeable.
Bon courage
++ R&B
Phil wrote:
Bonjour,
Plusieurs méthodes sont possible pour faire la saisie de chacune des lignes
des ventes dans une facture. À première vue, la saisie des données
directement depuis une table fichier ou mémoire avec entrée en cascade
semble toute indiqué pour cela.
De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up, ou
encore se positionne sur une ligne et presse la touche Delete on peut gérer
tout ça facilement j'imagine. Et comme l'usager est directement dans la
table, il peut facilement aller changer les quantités commandées ou vendues,
ou encore le prix unitaire si on lui en donne la permission.
Mais j'hésite et vous demande votre avis parce que le Manuel de
programmation de PCS mentionne à la section 12.4 de la page 326 « Les tables
fichiers sont essentiellement utilisées pour visualiser les données. Pour
saisir des données, il est préférable de le faire dans des champs de
saisie. ».
Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de la
page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en
saisie. »
Et pourtant la fonction de saisie en cascade existe et semble bien
fonctionner.
Pour ceux qui utilisent des saisies de lignes de commandes ou de factures
dans leurs applications, quelle méthode préférez-vous et pourquoi?
Quels sont les inconvénients véritables à utiliser une saisie en cascade
dans une table ? PCS le déconseille mais ne dit pas pourquoi.
Réal Phil
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur.
Néanmoins, nous avons effectivement abandonné systématiquement la saisie
dans les table... et encore moins dans les tables fichiers.
En effet, outre le problème du pointeur d'enregistrement (avec le
scrolling) se pose le problème des contrôles et de la validation des
saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui
doit être débranché pendant la saisie. la modification de chaque colonne
suppose-t elle celle de l'enregistrement ? Qui des contrôles
dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre
table_et_fiche ou l'utilisateur navigue entre les deux parties de la
fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier
une ligne. Evidement un jeu sur l'activation des groupes de champs
permet d'avoir une validation de la fiche indépendant de celle de la
fenêtre. Inutile alors de préciser que les contrôles nécesaires sont
tous à portée de programmation...
Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans
un table est utilisée :
- Une unique colonne en saisie (sélecteur/numérique)
- Table fichier basée sur un temporaire sans contrainte d'intégrité/blocage
- ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans
les projets d'envergure point n'est nécessaire de vouloir s'ajouter des
problèmes potentiels, il y en a généralement assez à résoudre. Parfois
'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à
même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de
perdre du temps sur la mise au point de règles d'interface avec pourquoi
pas des fenêtres modèles (RAD et autre). Ainsi en augmentant
l'uniformité de fonctionnement des modules de votre projet, vous
diminuerez les efforts de formation/support à produire ce qui est un
investissement non négligeable.
Plusieurs méthodes sont possible pour faire la saisie de chacune des lignes des ventes dans une facture. À première vue, la saisie des données directement depuis une table fichier ou mémoire avec entrée en cascade semble toute indiqué pour cela.
De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up, ou encore se positionne sur une ligne et presse la touche Delete on peut gérer tout ça facilement j'imagine. Et comme l'usager est directement dans la table, il peut facilement aller changer les quantités commandées ou vendues, ou encore le prix unitaire si on lui en donne la permission.
Mais j'hésite et vous demande votre avis parce que le Manuel de programmation de PCS mentionne à la section 12.4 de la page 326 « Les tables fichiers sont essentiellement utilisées pour visualiser les données. Pour saisir des données, il est préférable de le faire dans des champs de saisie. ».
Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de la page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en saisie. »
Et pourtant la fonction de saisie en cascade existe et semble bien fonctionner.
Pour ceux qui utilisent des saisies de lignes de commandes ou de factures dans leurs applications, quelle méthode préférez-vous et pourquoi?
Quels sont les inconvénients véritables à utiliser une saisie en cascade dans une table ? PCS le déconseille mais ne dit pas pourquoi.
Réal Phil
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur. Néanmoins, nous avons effectivement abandonné systématiquement la saisie dans les table... et encore moins dans les tables fichiers. En effet, outre le problème du pointeur d'enregistrement (avec le scrolling) se pose le problème des contrôles et de la validation des saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui doit être débranché pendant la saisie. la modification de chaque colonne suppose-t elle celle de l'enregistrement ? Qui des contrôles dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre table_et_fiche ou l'utilisateur navigue entre les deux parties de la fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier une ligne. Evidement un jeu sur l'activation des groupes de champs permet d'avoir une validation de la fiche indépendant de celle de la fenêtre. Inutile alors de préciser que les contrôles nécesaires sont tous à portée de programmation... Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans un table est utilisée : - Une unique colonne en saisie (sélecteur/numérique) - Table fichier basée sur un temporaire sans contrainte d'intégrité/blocage - ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans les projets d'envergure point n'est nécessaire de vouloir s'ajouter des problèmes potentiels, il y en a généralement assez à résoudre. Parfois 'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de perdre du temps sur la mise au point de règles d'interface avec pourquoi pas des fenêtres modèles (RAD et autre). Ainsi en augmentant l'uniformité de fonctionnement des modules de votre projet, vous diminuerez les efforts de formation/support à produire ce qui est un investissement non négligeable.
Bon courage
++ R&B
Phil
Merci pour cette explication vécue qui me guide beaucoup.
Cordialement,
Réal Phil
"Romuald.besset" a écrit dans le message de news:chm6kq$iq7$
Phil wrote: > Bonjour, > > Plusieurs méthodes sont possible pour faire la saisie de chacune des
lignes
> des ventes dans une facture. À première vue, la saisie des données > directement depuis une table fichier ou mémoire avec entrée en cascade > semble toute indiqué pour cela. > > De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up,
ou
> encore se positionne sur une ligne et presse la touche Delete on peut
gérer
> tout ça facilement j'imagine. Et comme l'usager est directement dans la > table, il peut facilement aller changer les quantités commandées ou
vendues,
> ou encore le prix unitaire si on lui en donne la permission. > > Mais j'hésite et vous demande votre avis parce que le Manuel de > programmation de PCS mentionne à la section 12.4 de la page 326 « Les
tables
> fichiers sont essentiellement utilisées pour visualiser les données.
Pour
> saisir des données, il est préférable de le faire dans des champs de > saisie. ». > > Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de
la
> page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en > saisie. » > > Et pourtant la fonction de saisie en cascade existe et semble bien > fonctionner. > > Pour ceux qui utilisent des saisies de lignes de commandes ou de
factures
> dans leurs applications, quelle méthode préférez-vous et pourquoi? > > Quels sont les inconvénients véritables à utiliser une saisie en cascade > dans une table ? PCS le déconseille mais ne dit pas pourquoi. > > Réal Phil > >
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur. Néanmoins, nous avons effectivement abandonné systématiquement la saisie dans les table... et encore moins dans les tables fichiers. En effet, outre le problème du pointeur d'enregistrement (avec le scrolling) se pose le problème des contrôles et de la validation des saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui doit être débranché pendant la saisie. la modification de chaque colonne suppose-t elle celle de l'enregistrement ? Qui des contrôles dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre table_et_fiche ou l'utilisateur navigue entre les deux parties de la fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier une ligne. Evidement un jeu sur l'activation des groupes de champs permet d'avoir une validation de la fiche indépendant de celle de la fenêtre. Inutile alors de préciser que les contrôles nécesaires sont tous à portée de programmation... Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans un table est utilisée : - Une unique colonne en saisie (sélecteur/numérique) - Table fichier basée sur un temporaire sans contrainte
d'intégrité/blocage
- ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans les projets d'envergure point n'est nécessaire de vouloir s'ajouter des problèmes potentiels, il y en a généralement assez à résoudre. Parfois 'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de perdre du temps sur la mise au point de règles d'interface avec pourquoi pas des fenêtres modèles (RAD et autre). Ainsi en augmentant l'uniformité de fonctionnement des modules de votre projet, vous diminuerez les efforts de formation/support à produire ce qui est un investissement non négligeable.
Bon courage
++ R&B
Merci pour cette explication vécue qui me guide beaucoup.
Cordialement,
Réal Phil
"Romuald.besset" <info@_pasdespam_rbesset.net> a écrit dans le message de
news:chm6kq$iq7$1@s5.feed.news.oleane.net...
Phil wrote:
> Bonjour,
>
> Plusieurs méthodes sont possible pour faire la saisie de chacune des
lignes
> des ventes dans une facture. À première vue, la saisie des données
> directement depuis une table fichier ou mémoire avec entrée en cascade
> semble toute indiqué pour cela.
>
> De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up,
ou
> encore se positionne sur une ligne et presse la touche Delete on peut
gérer
> tout ça facilement j'imagine. Et comme l'usager est directement dans la
> table, il peut facilement aller changer les quantités commandées ou
vendues,
> ou encore le prix unitaire si on lui en donne la permission.
>
> Mais j'hésite et vous demande votre avis parce que le Manuel de
> programmation de PCS mentionne à la section 12.4 de la page 326 « Les
tables
> fichiers sont essentiellement utilisées pour visualiser les données.
Pour
> saisir des données, il est préférable de le faire dans des champs de
> saisie. ».
>
> Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de
la
> page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en
> saisie. »
>
> Et pourtant la fonction de saisie en cascade existe et semble bien
> fonctionner.
>
> Pour ceux qui utilisent des saisies de lignes de commandes ou de
factures
> dans leurs applications, quelle méthode préférez-vous et pourquoi?
>
> Quels sont les inconvénients véritables à utiliser une saisie en cascade
> dans une table ? PCS le déconseille mais ne dit pas pourquoi.
>
> Réal Phil
>
>
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur.
Néanmoins, nous avons effectivement abandonné systématiquement la saisie
dans les table... et encore moins dans les tables fichiers.
En effet, outre le problème du pointeur d'enregistrement (avec le
scrolling) se pose le problème des contrôles et de la validation des
saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui
doit être débranché pendant la saisie. la modification de chaque colonne
suppose-t elle celle de l'enregistrement ? Qui des contrôles
dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre
table_et_fiche ou l'utilisateur navigue entre les deux parties de la
fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier
une ligne. Evidement un jeu sur l'activation des groupes de champs
permet d'avoir une validation de la fiche indépendant de celle de la
fenêtre. Inutile alors de préciser que les contrôles nécesaires sont
tous à portée de programmation...
Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans
un table est utilisée :
- Une unique colonne en saisie (sélecteur/numérique)
- Table fichier basée sur un temporaire sans contrainte
d'intégrité/blocage
- ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans
les projets d'envergure point n'est nécessaire de vouloir s'ajouter des
problèmes potentiels, il y en a généralement assez à résoudre. Parfois
'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à
même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de
perdre du temps sur la mise au point de règles d'interface avec pourquoi
pas des fenêtres modèles (RAD et autre). Ainsi en augmentant
l'uniformité de fonctionnement des modules de votre projet, vous
diminuerez les efforts de formation/support à produire ce qui est un
investissement non négligeable.
Merci pour cette explication vécue qui me guide beaucoup.
Cordialement,
Réal Phil
"Romuald.besset" a écrit dans le message de news:chm6kq$iq7$
Phil wrote: > Bonjour, > > Plusieurs méthodes sont possible pour faire la saisie de chacune des
lignes
> des ventes dans une facture. À première vue, la saisie des données > directement depuis une table fichier ou mémoire avec entrée en cascade > semble toute indiqué pour cela. > > De plus, si l'usager remonte plus haut avec la flèche ou avec Page Up,
ou
> encore se positionne sur une ligne et presse la touche Delete on peut
gérer
> tout ça facilement j'imagine. Et comme l'usager est directement dans la > table, il peut facilement aller changer les quantités commandées ou
vendues,
> ou encore le prix unitaire si on lui en donne la permission. > > Mais j'hésite et vous demande votre avis parce que le Manuel de > programmation de PCS mentionne à la section 12.4 de la page 326 « Les
tables
> fichiers sont essentiellement utilisées pour visualiser les données.
Pour
> saisir des données, il est préférable de le faire dans des champs de > saisie. ». > > Même chose pour les tables mémoires, on peut lire à la section 12.6.2 de
la
> page 328 du même manuel « Il est déconseillé d'utiliser des colonnes en > saisie. » > > Et pourtant la fonction de saisie en cascade existe et semble bien > fonctionner. > > Pour ceux qui utilisent des saisies de lignes de commandes ou de
factures
> dans leurs applications, quelle méthode préférez-vous et pourquoi? > > Quels sont les inconvénients véritables à utiliser une saisie en cascade > dans une table ? PCS le déconseille mais ne dit pas pourquoi. > > Réal Phil > >
Bonjour,
Sur ce sujet, les avancée de wd8 premettent peut-être d'être meilleur. Néanmoins, nous avons effectivement abandonné systématiquement la saisie dans les table... et encore moins dans les tables fichiers. En effet, outre le problème du pointeur d'enregistrement (avec le scrolling) se pose le problème des contrôles et de la validation des saisies...
Souvent les tables fichiers on un raffraîchissement automatique... qui doit être débranché pendant la saisie. la modification de chaque colonne suppose-t elle celle de l'enregistrement ? Qui des contrôles dintégrité et des blocages réseaux...
Ainsi, nous avons privilégié (et adapté à notre besoin) les fenêtre table_et_fiche ou l'utilisateur navigue entre les deux parties de la fenêtre : la table pour naviguer dans le fichier, la fiche pour modifier une ligne. Evidement un jeu sur l'activation des groupes de champs permet d'avoir une validation de la fiche indépendant de celle de la fenêtre. Inutile alors de préciser que les contrôles nécesaires sont tous à portée de programmation... Néanmoins nous nous sommes réservé quelques exceptions ou la saisie dans un table est utilisée : - Une unique colonne en saisie (sélecteur/numérique) - Table fichier basée sur un temporaire sans contrainte
d'intégrité/blocage
- ordre de parcours non modifiable
Tout cela, pour conserver la plus grande robustesse possible car dans les projets d'envergure point n'est nécessaire de vouloir s'ajouter des problèmes potentiels, il y en a généralement assez à résoudre. Parfois 'apauvrir' peut être aussi un gage d'efficacité, vous êtes toujours à même d'évoluer par la suite... avec la maîtrise.
En tout cas, avant de commencer, il peut être effectivement judicieux de perdre du temps sur la mise au point de règles d'interface avec pourquoi pas des fenêtres modèles (RAD et autre). Ainsi en augmentant l'uniformité de fonctionnement des modules de votre projet, vous diminuerez les efforts de formation/support à produire ce qui est un investissement non négligeable.
