FORUM WINDEV

Bonjour à Tous,

J'aimerai bien connaitre le choix et le pourquoi du développeur que vous êtes, entre table mémoire ou table fichier, quand il s'agit de traiter par exemple, une gestion commerciale Bon de commande, bon de livraison ou vente; Et je précise tout en faisant attention aux mouvements du stock.

Le débat est ouvert et j'invite tous les membres du forum à y participer.
Faut pas hésiter soyez nombreux à y participer

@+
.

Bonjour,

Alors la réponse est quand même déjà en partie donnée dans l'aide WD

En fait cela dépend réellement de ce que tu souhaites faire précisément :

Pour manipuler des données issues par exemple de tes fichiers clients, articles, stocks... la table mémoire est indiquée car tu va l'alimenter par programmation, avec les éléments que tu auras choisis.

Pour manipuler des données directement dans le fichier, par exemple saisir des sorties de stock, la table fichier est indiquée, car tu vas sélectionner dans ta table les lignes et effectuer les maj.

Chaque type a un traitement particulier, l'aide est très explicite la-dessus.

Enfin, comme toujours, cela dépend beaucoup des habitudes de programmation : pour ma part j'utilise très rarement les tables fichiers et je privilégie (peut-être à tort ) les vues qui alimentent mes tables mémoires. Les différents test effectués sur mes applications ( compta, gestion stocks, facturation,etc) ont démontrés à chaque fois un plus incontestable avec cette méthode. Encore une fois, je pense qu'il n'y a pas de bon et de mauvais, il faut adapter au cas par cas.

J'espère t'éclairer (celle là, elle est facile !) un peu.

Bon dev, Daniel.

Salut Daniel,

J'ai toujours travaillé avec les table fichiers, et comme je vois sur le forum beaucoup de membres qui utilisent les tables mémoires, je commence à me poser des questions...

Je prend l'exemple de trois (3) commerciaux, chacun devant son PC et son client juste en face, les clients passent leur commande disant pour le même produit qui n'est pas en quantité suffisante pour les trois clients, premier arrivé premier servi...

Quelles sont les meilleurs dispositions à prendre, en utilisant les table mémoire, pour éviter à avoir des problèmes avec le stock ?


Merci d'avance
.

Salut PetitPoussin,

En fait la réponse à ta question de stock est : tout dépend comment l'information est traîtée, donc de ton code ! Les tables n'y sont pour rien là-dedans

Si tu as une table fichier, cela suppose qu'à la saisie et validation de la ligne, la maj soit effectuée, mais c'est la même chose avec la table mémoire si tu codes ta maj en sortie de saisie... C'est le traitement qui fait la différence (vois sur ce point les différences dans l'aide).

Ceci étant, dans ce cas précis, la table fichier est plus indiquée (à mon avis).

Comme je l'écrivais, il n'y a pas de bonne ou mauvaise manière : il faut bien analyser et décomposer les traitements à réaliser et tester éventuellement les deux types pour retenir le plus efficace.

En fait ta question c'est presque "Est-ce qu'une Renault c'est mieux qu'une Peugeot ?"... tu auras des défenseurs des 2

A+

Bonjour à tous,

Et bien Daniel à fait le tour de la question.... je suis pareil, j'utilise le plus souvent des table mémoires car plus élastique je dirais, mais rien n'est obligatoire c'est selon le besoin.

Salut a tous
PetitPoisson je pense que Daniel t a deja trop eclaire (moi j'utilise jamais les table fichiers dans mes logi). Mais pour ton probleme de maj pour les trois clients alors que la quantite disponible ne poura pas satisfaire ces trois, tu devra gerer les blocage denregistrement au cas ou plusieur users voudront inserer en meme temps la vente. Donc fouille dans laide mot cle blocage.
Coordialement!

Bonjour tout le monde,

Merci à tout les Trois, et en suivant vos conseils pour les prochaines fois je vais utiliser les tables mémoire, pour profiter de leurs souplesses.

Encore Merci.

Attention pour les tables mémoire , il faut quant même prendre quelques précautions :
1- si elles sont remplies par programmation il faut désactiver la propriété Déplaçable des colonnes ,sinon si l'utilisateur
change l'ordre des colonnes --> catastrophe .
2-si elles sont utilisées pour la saisie avant l'ajout dans le fichier , il faut mettre en tète que l'utilisateur peut sortir accidentellement de la table sans enrigistrer les données , là toutes les lignes saisies seront perdus.

gwing a écrit:Attention pour les tables mémoire , il faut quant même prendre quelques précautions :
1- si elles sont remplies par programmation il faut désactiver la propriété Déplaçable des colonnes ,sinon si l'utilisateur
change l'ordre des colonnes --> catastrophe .

Euh Gwing je n'ai pas tout à fait compris...
Je laisse toujours le choix de déplacer les colonnes ds mes tables mémoire sans souci, du moment que dans le code l'ordre est respectée avec les noms de colonnes
Tableajouteligne(Table,COL_1,COL_2,COL_3)

Par contre mon choix s'est porté sur les tables mémoire à cause du nombre d'enregistrements dans un fichier HF.
Je ne sais pas si cela est dû à la propriété nombre chargé en mémoire, mais l'affichage de ma table ramait avec un nombre élevé d'enregistrements.

Bon DEV

Si le fichier est à afficher en entier, la table fichier est plus rapide.
Par contre dès qu'il y a nécessité d'effectuer un filtre préalable, la table mémoire est gagnante.
Mais c'est surtout ce que l'on veut faire avec cette table qui conditionne le choix.

gwing a écrit:Attention pour les tables mémoire , il faut quant même prendre quelques précautions :
1- si elles sont remplies par programmation il faut désactiver la propriété Déplaçable des colonnes ,sinon si l'utilisateur
change l'ordre des colonnes --> catastrophe .

Gwing a raison....

Si on écrit comme ceci il faut désactiver le déplacement des colonnes;

Code: Tout sélectionner

NomFichier.NomRubrique = TABLE_Table1[nLig][nCol]     //... car la colonne déplacée perd pas sa valeur initiale

...

Mais écrit comme ceci il n'est pas nécessaire de désactiver le déplacement des colonnes;

Code: Tout sélectionner

NomFichier.NomRubrique = TABLE_Table1.Colonne1[nLig]   //....  car la colonne déplacée garde sa valeur initiale
...

Et si cette façon de faire n'est pas respectée, gare aux problèmes...

ok je comprends mieux!
Ouf je me voyais déjà en train de ...