Discussion :

[Julien Dufour]

Bonjour,

J'aimerais utiliser access pour gérer le suivi d'avancement de plusieurs traitement automatisés.

Comme je dois en lancer plusieurs en simultané, j'aimerais savoir s'il est possible de gérer le multi-thread avec access.

[argyronet]

Bonjour,

Quels genres de traitements automatisés ?

Argy

[Julien Dufour]

En fait, je souhaiterais lancer plusieures bases access qui gèrent l'extraction de données de différentes sources, leurs traitements (5 traitements différents) et l'exportation des résultats sous différents format.

La contrainte est que les données sources ne sont disponibles que pendant un laps de temps très court qui est insuffisant pour rapatrier l'ensemble des données. Je dois donc gérer plusieurs rapatriement simultanés.

De plus certains traitements dépendent du bon déroulement des traitements précédent. Il faut donc que je les gère en un seul lieu pour pouvoir organiser les enchainement.

Je pourrais faire une usine à gaz avec lancement simultanés des bases et gestion de paramètres de suivi d'avancement "partagés" dans un .ini sur le réseau. Mais ce serait lourd et long. Je préfère vérifier s'il n'est pas possible d'utiliser des thread.

[FRED.G]

La réponse à ta question peut être ici : http://access.developpez.com/sources/

Merci de faire plus de recherche avant de poster sur le forum

[Julien Dufour]

Argh

J'avoue avoir craqué après la troisième recherche sur "thread" qui ne me renvoyé que des post sous delphi...

[argyronet]

Re,

Il faut que tu réagisses comme avec un EAI...
Un gestionnaire de flux en quelque sorte.
Cela va t'obliger à créer des DLL qui vont servir de moteur pour connaitre la disponibilité (établie à l'avance ou en temps et/ou en heure) et renvoyer ces informations dans ta base Access maîtresse.
Ces DLL tournent d'elles-mêmes à partir du moment où ton appli maîtresse tourne elle aussi puisque c'est elle qui les a lancé.
A ce stade, ta base Access sait à quel moment elle doit faire telle ou telle transaction.
A chaque fois qu'une mission (flux) est remplie, la DLL change l'information dans ta base maîtresse qui sait alors qu'elle n'a plus à traiter cette tâche. Et ainsi de suite...

Je vois cela comme ça car j'ai bossé sur un outil de CRM qui tournait sur un équivalent de BizTalk en VB6 et en .Net. C'est pour cela que ta demande m'a fait pensé à cette idée.
En revanche, tu as du taff devant toi.

Argy

[Julien Dufour]

Yep,

Malheureusement, je fais tout ça en plus de mon taff pour me simplifier la vie. Alors si cela devient un peu trop long à développer, je suis bien obliger d'abandonner.

J'avoue ne pas avoir bien compris ta solution.
- C'est quoi un EAI ?
- Je pensais que l'intéret des DLL se limitait à mettre à disposition de nouvelles fonctions. Comment peux-t'on en faire un moteur pour connaître la disponibilité ?

J'avoue que je pensais bêtement lancer des thread commençant tous par une boucle while permettant d'attendre un feu vert données par les valeurs de différentes variables globales conjuguées. Ces variables globales étant mises à jour par la fin des traitements lancés par les thread.

Désolé, ça fait 7 ans que j'ai quitter le code. Ma connaissance s'est arrêté à C++ sous UNIX avec un éditeur de fenêtre fait à partir de DLL maison

[argyronet]

Bonjour,

EAI: Enterprise Application Integration.
Le but du jeu est de faire fonctionner ensemble (en particulier en matière d'échange transparent de données)
les programmes existants dans une entreprise, en vérifiant leur interopérabilité et gérer l'hétérogénéité générale.

DLL peuvent s'auto-exécuter, euh, oui et non en fait; Elle ont besoin d'un ordre (flux XML par exemple) qu'elles lisent et agissent en fonction.
Bon, c'est un peu vague comme ça, mais je t'ai simplement suggéré de t'en inspirer. Le principe est que tu pourrais mettre en place un système similaire qui fonctionnerait un peu comme le plannificateur de tâches de Windows.
Je ne sais pas si ça peut t'aider, c'est une piste...

Argy

[Julien Dufour]

OK merci pour les infos.

Y'a plus qu'a