Discussion :

[salimdz]

Bonjour

J’ai un programme de traitement des salaires il est très lent, et aussi il devient très lent avec l’augmentation des nombre d’enregistrements dans la base bulletin et détail bulletin

J’utilise plusieurs base en même temps pour faire ce traitement, une base bulletin et une base rubrique bulletin (détail bulletin), et un autre base Rubrique (formule du calcul)

les bases il sent en Paradox,

Merci d’avance

[Rayek]

Utilises tu des TQuery ou seulement de TTable ?
Si tu utilises des TTables, il faudrait que tu changes de fonctionnement et que tu passes par l'utilisation des requetes avec les TQuery.

[ALWEBER]

Il y a plusieurs pistes possibles, mais d'abord quelques informations :

Combien d'enregistrements dans tes tables,
Structure des champs composant la clé primaire,
Nombre d'utilisateurs utilisant cette application

Avec ces infos je pourrai t'aider.

[franck SEFIC]

envoie nous les tables et leurs structures, en plus on veut savoir comment ta codé? s'il y a des requettes , des procedures, des fonctions,...

Moi j'ai un logciel de paie qui calcule 300 salariés en 3mn

[salimdz]

Utilises tu des TQuery ou seulement de TTable ?
Si tu utilises des TTables, il faudrait que tu changes de fonctionnement et que tu passes par l'utilisation des requetes avec les TQuery.

merci pour votre reponse
j'utilise TTable seulement,
svp tu pense à quoi comme cause
a+

[dd_garion]

Désolé, mais sans plus d'informations, nous allons avoir dure à t'aider.

Y a t'il des index dans tes tables ?
Comment est structuré ton code ?
Comment est structuré ton projet ?

ETC... sans compter les questions des autres membres.

[salimdz]

Il y a plusieurs pistes possibles, mais d'abord quelques informations :

Combien d'enregistrements dans tes tables,
Structure des champs composant la clé primaire,
Nombre d'utilisateurs utilisant cette application

Avec ces infos je pourrai t'aider.

merci pour votre réponse

--Combien d'enregistrements dans tes tables
dans la table Employe 1680 enregistrements, mais il ya que 1200 qui sent active pour le traitement

dans la table Bulletin 12200 enregistrements

dans la table LinBull 141240 enregistrements

il ya d'autre table comme Absence et CongeMaladie ...

--Structure des champs composant la clé primaire
la table Employe il y a tous les information d'une personnel,

clé Matricule seulement

la table Bulletin il y a le Matricule, le mois l'année .... Fonction, Categorie, Section ..., SoumisIRG, Brut, Retenue, NetPayer ...

clé Matricule, Num(+)

dans la table LinBull il y a Code (le Num de table Bulletin), Code_Rub, Base, Taux, Montant, Imposable, Cotisable,

clé Code, Code_Rub, Num(+)

Nombre d'utilisateurs utilisant cette application
l'application il est en version mono poste base Paradox

[salimdz]

envoie nous les tables et leurs structures, en plus on veut savoir comment ta codé? s'il y a des requettes , des procedures, des fonctions,...

merci pour votre réponse,

Moi j'ai un logciel de paie qui calcule 300 salariés en 3mn

ca pour moi un rêve, elle développer sur quelle type de base et avec quel langage, moi 12000 en 22 heure, et aussi avant elle été en 6 heure, le problème avec l'augmentation de la base Bulletin et LinBull elle deviens très très lent

[salimdz]

Désolé, mais sans plus d'informations, nous allons avoir dure à t'aider.

Y a t'il des index dans tes tables ?
Comment est structuré ton code ?
Comment est structuré ton projet ?

ETC... sans compter les questions des autres membres.

merci pour votre réponse

oui il ya des index dans les tables

pour le code il ya une unité bulletin pour ajoute les bulletin avec plusieurs procédure et fonction

unité de calcul des rubriques avec plusieurs fonction et procédure

et il ya les masques pour la saisie et la modification des informations

[liazidf]

salut,
je pense que le problème vient de la façon dont vous faite le calcul, vous devez certainement effectuer l'accé aux tables pour chaque rubrique que vous calculez, essayer plutôt les tables mémoire pour estimer les temps.
bon courage

[salimdz]

salut,
je pense que le problème vient de la façon dont vous faite le calcul, vous devez certainement effectuer l'accé aux tables pour chaque rubrique que vous calculez, essayer plutôt les tables mémoire pour estimer les temps.
bon courage

salut,
merci pour votre réponse,
oui je fait l'accé au table pour chaque rubrique,
comment les tables mémoires, j'ai jamais utilisé ca, si tu peut me donne un exemple

[Aka Guymelef]

Bonjour,

Je suppose que pour vos calcul vous avez des informations fixes qui ne bougent pas (durant la phase de calcul) notamment les fameux base/taux/montant des rubriques de paye.
L'idée c'est d'éviter d'aller faire une requête unitaire juste pour récupérer une valeur de rubrique qui se répète pour chaque salarié.
Plus généralement l'idée serait plutôt de faire des requête de masse, de stocker ceci dans des DataSets et d'utiliser les DataSets pour rechercher les infos plutôt que de faire des accès BDD. Je suppose que c'est cela que voulais dire liazidf avec ses "tables mémoires".

Pour reprendre les rubriques de paye moi je verrais bien une classe qui encapsule un DataSet, une méthode Charger pour aller chercher toutes les rubriques utiles et les stocker dans le DataSet. Une méthode pour récupérer la valeur en lui passant le code de la rubrique, pour ce faire utiliser un locate sur l'objet DataSet pour retrouver l'enregistrement correspondant (positionner un index sur le code dans le DataSet pour maximiser les temps de réponses pour la recherche).
Enfin pour les rubriques qui sont utilisées tout le temps, je pense qu'il serait bon de les extraire (à l'initialisation avant le lancement des calculs) dans des propriétés de la classe, et ensuite dès que le programme sait qu'il doit récupérer les infos de ces rubriques en particulier il récupère directement la propriété plutôt que de passer par le Locate.

[Archibald29]

Bonjour,

1 - Avez vous envisagé de mettre en place des tables "d'archivage" de façon à minimiser le volume des tables dans lesquelles les données "utiles" sont recherchées ? (il semble que votre durée de traitement augmente de façon exponentielle comme si l'on traitait des éléments archivables)

2 - Vous pourriez également mettre en place un mode "test" qui mesurerait les durées de traitement à l'intérieur de chaque boucle de façon à savoir où se situent les procédures qui prennent le plus de temps. (par exemple en basculant aprés appui sur une touche de fonction je passe en mode Test, et à partir de là je prends un TimeStamp à l'entrée et à la sortie de chaque procédure, et en stockant les durées par procédure dans une table annexe).

[salimdz]

Bonjour,

1 - Avez vous envisagé de mettre en place des tables "d'archivage" de façon à minimiser le volume des tables dans lesquelles les données "utiles" sont recherchées ? (il semble que votre durée de traitement augmente de façon exponentielle comme si l'on traitait des éléments archivables)

salut
merci pour votre réponse
j'ai pense à faire une base pour la derniers bulletin par personne, mais j'ai pensé quelle prend de temps pour la Remplier

2 - Vous pourriez également mettre en place un mode "test" qui mesurerait les durées de traitement à l'intérieur de chaque boucle de façon à savoir où se situent les procédures qui prennent le plus de temps. (par exemple en basculant aprés appui sur une touche de fonction je passe en mode Test, et à partir de là je prends un TimeStamp à l'entrée et à la sortie de chaque procédure, et en stockant les durées par procédure dans une table annexe).

une bonne idée pour connaitre le temps d'exécution pour chèque procédures

[salimdz]

Bonjour,

Je suppose que pour vos calcul vous avez des informations fixes qui ne bougent pas (durant la phase de calcul) notamment les fameux base/taux/montant des rubriques de paye.
L'idée c'est d'éviter d'aller faire une requête unitaire juste pour récupérer une valeur de rubrique qui se répète pour chaque salarié.
Plus généralement l'idée serait plutôt de faire des requête de masse, de stocker ceci dans des DataSets et d'utiliser les DataSets pour rechercher les infos plutôt que de faire des accès BDD. Je suppose que c'est cela que voulais dire liazidf avec ses "tables mémoires".

Pour reprendre les rubriques de paye moi je verrais bien une classe qui encapsule un DataSet, une méthode Charger pour aller chercher toutes les rubriques utiles et les stocker dans le DataSet. Une méthode pour récupérer la valeur en lui passant le code de la rubrique, pour ce faire utiliser un locate sur l'objet DataSet pour retrouver l'enregistrement correspondant (positionner un index sur le code dans le DataSet pour maximiser les temps de réponses pour la recherche).

salut,
merci pour votre réponse
le problème que les rubrique change d'une personne à une autre tu peut dire qu'il y a plusieurs groupe de personne,

j'ai pas essayer de stocké la base rubrique dans un DataSet, et aussi il ya le problème des des sommes des Linbulletin pour calculer le brut ou irg ... pour chaque bulletin

Enfin pour les rubriques qui sont utilisées tout le temps, je pense qu'il serait bon de les extraire (à l'initialisation avant le lancement des calculs) dans des propriétés de la classe, et ensuite dès que le programme sait qu'il doit récupérer les infos de ces rubriques en particulier il récupère directement la propriété plutôt que de passer par le Locate.

j'ai jamais utilise des classe et les propriétés de classe

[Aka Guymelef]

Bonjour,

Pour moi ce qui plombe le traitement (d'après ce que vous avez dit) ce sont les accès incessant (et unitaire) à la base de données pour aller chercher chaque information pour pouvoir faire le calcul. Il faut essayer de grouper et mutualiser au maximum. en clair ce n'est pas la base de données qui doit travailler mais bel et bien le programme.

Dans cette logique les éléments fixes du calcul (comme les rubriques de paye) doivent être chargées en une seule fois et une et une seule fois au début du programme. Et après on fait des recherches dans le DataSet "référentiel".

Ici j'ai bien parlé des rubriques de paye soit la table de référence où se trouve tout les codes de rubriques ainsi que leur taux/base/montant associés. Je ne parlais pas de la liaison entre ces rubriques et les salariés qui doivent être dans une autre table à priori.

Pour revenir aux salariés là aussi il faut grouper, charger tout les salariés à calculer avec leurs rubriques associées puis diviser dans le programme salarié par salarié.

C'est bien dommage que vous ne sachiez pas utiliser les classes car je suis sûr que ça vous aiderez beaucoup rien que dans la lisibilité, la structure et la maintenabilité du code.

[salimdz]

Bonjour,

Pour moi ce qui plombe le traitement (d'après ce que vous avez dit) ce sont les accès incessant (et unitaire) à la base de données pour aller chercher chaque information pour pouvoir faire le calcul. Il faut essayer de grouper et mutualiser au maximum. en clair ce n'est pas la base de données qui doit travailler mais bel et bien le programme.

Dans cette logique les éléments fixes du calcul (comme les rubriques de paye) doivent être chargées en une seule fois et une et une seule fois au début du programme. Et après on fait des recherches dans le DataSet "référentiel".

Ici j'ai bien parlé des rubriques de paye soit la table de référence où se trouve tout les codes de rubriques ainsi que leur taux/base/montant associés. Je ne parlais pas de la liaison entre ces rubriques et les salariés qui doivent être dans une autre table à priori.

Pour revenir aux salariés là aussi il faut grouper, charger tout les salariés à calculer avec leurs rubriques associées puis diviser dans le programme salarié par salarié.

bonjour
merci pour votre réponse
moi aussi je pense que l'accée au base de donnée qui rende le programme très lent,
je pensé à faire change les procédure avec des requête SQL

C'est bien dommage que vous ne sachiez pas utiliser les classes car je suis sûr que ça vous aiderez beaucoup rien que dans la lisibilité, la structure et la maintenabilité du code.

ta pas un exemples pour cette technique

[Aka Guymelef]

Pour ce qui est de la construction de classe et leur utilisation (ce qu'on appelle la programmation objet) je préfère te renvoyer vers un tutoriel du site pour que tu y apprennes les bases ici. Après si tu n'arrives pas à construire tes classes métiers, on pourra toujours t'aider là-dessus. Mais avant mieux vaut commencer par maîtriser les bases.

[salimdz]

Pour ce qui est de la construction de classe et leur utilisation (ce qu'on appelle la programmation objet) je préfère te renvoyer vers un tutoriel du site pour que tu y apprennes les bases ici. Après si tu n'arrives pas à construire tes classes métiers, on pourra toujours t'aider là-dessus. Mais avant mieux vaut commencer par maîtriser les bases.

salut
merci pour votre aide,
et pour ce lien,
réellement le principe je le connue, j’ai l’étudier avent plusieurs fois, mais le problème que j’ai pas l’habitude de développez avec cette technique

[Aka Guymelef]

Il faut voir une classe comme étant : techniquement une encapsulation d'un ou plusieurs éléments et fonctionnellement comme un travailleur spécialisé. Ainsi chaque classe (ou objet) va être dédié à faire les actions propre à une partie du métier. Et l'ensemble des classes permettra de réaliser l'objectif voulu, en faisant en sorte que chaque classe communique avec les autres.

Dans votre cas par exemple on pourrait très bien avoir le découpage suivant :

- une classe qui gère les rubriques de paye (référentiel) déclaré en variable globale, capable de charger les données et de récupérer les informations suivant le code de rubrique passé.

- une classe qui gère la liste des salariés, c'est le point d'entrée du programme, il charge la liste des salariés à traiter puis parcours ce DataSet et créé un objet bulletin (voir ci-dessous), initialise toutes ses propriétés, et demande au bulletin de se calculer et de s'enregistrer en base

- une classe bulletin, c'est le cœur du métier, il attends que certaines propriétés soient chargées pour fonctionner (idSalarie, ses rubriques de paye afférentes, et tout autres données nécessaire) et possède une fonction de calcul qui va créer autant de ligne au bulletin que de rubrique auquel le salarié à droit (en utilisant la classe de référentiel pour calculer les rubriques) puis fait l'insertion en base de donnée une fois le traitement terminé.