Discussion :

[krib]

Bonjour à tous,

j'ai l'impression d'avoir à réinventer l'eau chaude.

Un cas classique :

Une table d'entête de commandes fournisseurs avec une clé primaire sur champ numéro de commande en numéro auto. Relation 1 à plusieurs avec une table détail de commandes (clé étrangère : numéro de commande).

Pour saisir tout ca, j'emploie un formulaire pour l'entête et un sous-formulaire pour les détails.

Ma question n'est pas de savoir quelles méthodes existent (j'ai lu pratiquement tout le site) mais plutot : Quelle méthode est employée le plus souvent par les pros ? :

1- Les deux formulaires connectés?
2- Un des deux non connecté et mise jour des tables via un recordset fait main?
3- Les deux formulaires deconnectés?

Je sais que le sujet a été traité des millions de fois mais je ne sais pas en revanche quelle est la méthode considerée par les pros comme faisant partie des "règles de l'art".

Pardon pour une question si générique mais parfois l'embarras du choix ne facilite pas la vie

[Heureux-oli]

A mon avis, et nous allons tous avoir des avis différents.
Je privilégie la clarté et la facilité au niveau de l'utilisateur.

Plus c'est simple et transparent, moins tu auras d'erreurs.

Crois moi, les utilisateurs sont assez fort pour le b.......

[FreeAccess]

Bonjour,
Sans être un Pro..loin de là......

La solution d'un formulaire principal (en-tête facture) et d'un sous-formulaire (détails facture) me semble pratique et facile à mettre en oeuvre...

Ceci n'est que mon opinion...

[Invité]

Bonjour

D'accord avec FreeAccess, cette méthode est la plus simple.

Personnellement je préfère tout géré par des recordset, car je le fais aussi en VB6, cela me permet d'homogénéiser mon code et dés fois de prendre des bouts de codes pour passer de l'un à l'autre.

je ne connais pas ton niveau, mais avec les deux formulaires intégrés, moins du code, et contrôle des intégrités automatique par Access (si celles-ci sont bien déclarés)

Starec

[krib]

La solution d'un formulaire principal (en-tête facture) et d'un sous-formulaire (détails facture) me semble pratique et facile à mettre en oeuvre...

c'est ce que je fais mais ce n'était pas la question

[Invité]

Re

Comme dit Heureux-Oli, les avis serons différents, il n'y a pas de mauvaises méthodes, il y'a celle qui nous plait, et que l'on met en oeuvre facilement.

Starec

[FreeAccess]

Re,

c'est ce que je fais mais ce n'était pas la question

Pourtant c'était ma réponse....donc je prenais l'option 1..

1- Les deux formulaires connectés? :

[krib]

C'est amusant, j'étais persuadé qu'une des méthodes avait la faveur d'une majorité de développeurs.

Pour ma part, je suis resté sur form et sousform connectés (table et requète) et contrôle de ce qui est saisi dans chaque champ en fonction des évènements (before update etc...).

[FRED.G]

Je ne prétend pas donner le point de vue d'un pro, mais à mon sens, Access n'a d'intérêt que pour des applis dans lesquelles on peut utiliser à fond ses possibilités de binding automatique (c'est à dire les formulaires dépendants), et le contrôle de la saisie au niveau des contrôles (propriétés format / masque de saisie / valide si) et du formulaire (événements AvantMaj, etc.).

Sinon pour faire vraiment propre, à savoir développer de vraies classes métier distinctes des composants d'interface utilisateur, autant utiliser un environnement plus favorable comme Visual Studio en .NET.

[loufab]

Bonjour,
Je mets mon grain de sel ...

Je dirais tout dépend de la charge de l'application et de l'infrastrucure à ta disposition.

Si peu de charge = tout connecté.
Si très forte charge = tout déconnecté.

Soit on le prévoit dès le début, soit on revient sur l'appli une fois confronté au problème.

Cordialement,