J'ai une appli qui fonctionne en réseau et je souhaiterais lancer
quotidiennement un certain nombre de tâches.
-Réindexation de fichier
-Intérogation d'un service web
-MAJ de certaines fichiers
...
La solution de Timers présents sur des postes clients ne me plait pas,
suis je obligé de créer un nouveau projet "Admin" à partir de la même
analyse et l'installer en version monoposte sur un poste d'Admin.
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
Gégé
> J'ai une appli qui fonctionne en réseau et je souhaiterais lancer quotidiennement un certain nombre de tâches. -Réindexation de fichier -Intérogation d'un service web -MAJ de certaines fichiers
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une base HF à travers un navigateur. www.beaussier.com/wash/
> J'ai une appli qui fonctionne en réseau et je souhaiterais lancer
quotidiennement un certain nombre de tâches.
-Réindexation de fichier
-Intérogation d'un service web
-MAJ de certaines fichiers
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une
base HF à travers un navigateur.
www.beaussier.com/wash/
> J'ai une appli qui fonctionne en réseau et je souhaiterais lancer quotidiennement un certain nombre de tâches. -Réindexation de fichier -Intérogation d'un service web -MAJ de certaines fichiers
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une base HF à travers un navigateur. www.beaussier.com/wash/
stanislas
Merci pour la réponse, mais je réalise que je me suis mal exprimé, en fait je souhaite mettre en place des automatismes: -réindexation la nuit, intérogation d'un service web toutes les heures...
La fonction TimerSys me permet de réalise un certain nombre de choses mais je ne souhaites pas que tous les postes clients réalisent chacun de leur coté ces taches, je veux simplement qu'elles soient réalisés automatiquement à partir d'une seul appli (présente sur le serveur par exemple).
Je n'ai que cette solution qui ne me plait pas trop: -Créer une nouvelle appli d'"Admin" agissant sur les mémes données que mes apllis clients et dont l'unique fonction serait de lancer des taches automatiquement.
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une base HF à travers un navigateur. www.beaussier.com/wash/
Merci pour la réponse, mais je réalise que je me suis mal exprimé, en
fait je souhaite mettre en place des automatismes:
-réindexation la nuit, intérogation d'un service web toutes les
heures...
La fonction TimerSys me permet de réalise un certain nombre de choses
mais je ne souhaites pas que tous les postes clients réalisent chacun
de leur coté ces taches, je veux simplement qu'elles soient réalisés
automatiquement à partir d'une seul appli (présente sur le serveur par
exemple).
Je n'ai que cette solution qui ne me plait pas trop:
-Créer une nouvelle appli d'"Admin" agissant sur les mémes données que
mes apllis clients et dont l'unique fonction serait de lancer des
taches automatiquement.
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une
base HF à travers un navigateur.
www.beaussier.com/wash/
Merci pour la réponse, mais je réalise que je me suis mal exprimé, en fait je souhaite mettre en place des automatismes: -réindexation la nuit, intérogation d'un service web toutes les heures...
La fonction TimerSys me permet de réalise un certain nombre de choses mais je ne souhaites pas que tous les postes clients réalisent chacun de leur coté ces taches, je veux simplement qu'elles soient réalisés automatiquement à partir d'une seul appli (présente sur le serveur par exemple).
Je n'ai que cette solution qui ne me plait pas trop: -Créer une nouvelle appli d'"Admin" agissant sur les mémes données que mes apllis clients et dont l'unique fonction serait de lancer des taches automatiquement.
Tu peux utiliser le projet WDScript/WasH qui te permet d'administrer une base HF à travers un navigateur. www.beaussier.com/wash/
Romain PETIT
Stanislas avait énoncé :
Je n'ai que cette solution qui ne me plait pas trop: -Créer une nouvelle appli d'"Admin" agissant sur les mémes données que mes apllis clients et dont l'unique fonction serait de lancer des taches automatiquement.
Bonjour,
C'est en plein dans l'actualité en ce qui me concerne. Voilà les problèmes auxquels je suis confronté pour mon appli tâche de fond sur le serveur :
* fuite mémoire régulière et progressive. Pour l'instant je n'ai pas cerné précisément la ou les fonctions WD qui posent problème (il y avait eu la fonction fListeFichier avant la version 206g mais le problème a été résolu). Avec la 206g, au stade où j'en suis, je crois que HAjoute() pose un réel problème de libération de mémoire (dans certains cas que je dois encore déterminer). Mon appli utilise en continu les fonctions suivantes : - base HF (pas encore eu le temps de sauter le pas...) - fonctions FTP intégrés (très nombreux envois) - lecture, écriture, copies, suppressions de fichiers ASCII (en grand nombre) - utilisation de vues déclarées en "sources de données" (et libérées en fin de traitement) - utilisation de zones mémoires - des HAjoute, HModifie mais aucun HSupprime - une classe pour traçabilité dans des fichiers textes et un timer pour détecter le changement de jour J'ai externalisé dans un autre EXE (lancé quotidiennement) ma gestion d'archivage : pour certains fichiers très utilisés, je créé des alias mensuels, je copie les enregistrements du fichier actif (selon des critères de date) vers l'alias et je supprime ensuite l'enregistrement actif. Le blocage+réindexation a l'air également de bouffer de la mémoire sans la libérer, je vais bientôt l'externaliser également. Cela ne va malheureusement pas résoudre tous mes soucis de fuite mémoire...je cherche encore. La prochaine étape est de passer l'application en service pour voir si le problème ne vient pas des ressources graphiques de mon application (une fenêtre simple avec un bouton et un champ texte qui change de couleur lorsque des tâches sont actives, utilisation de ma classe cSystray pour l'iconisation).
* J'ai tenté de mettre les principales tâches dans des threads indépendants mais j'ai vite abandonné en constatant de nombreux problèmes avec un serveur Xeon Hyperthreadé sous Windows Serveur 2003 (erreurs fatales non catchées par EXCEPTION) alors que l'appli marchait correctement sous une station W2000 ou XP avec un processeur "normal". Je n'ai pas voulu aller plus loin et suis revenu à une boucle sans fin et séquentielle (les tâches sont lancées l'un après l'autre).
Je crois que je vais en venir à utiliser finalement une 3ème appli qui arretera et relancera chaque jour l'appli principale et l'appli de maintenance...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Stanislas avait énoncé :
Je n'ai que cette solution qui ne me plait pas trop:
-Créer une nouvelle appli d'"Admin" agissant sur les mémes données que
mes apllis clients et dont l'unique fonction serait de lancer des
taches automatiquement.
Bonjour,
C'est en plein dans l'actualité en ce qui me concerne.
Voilà les problèmes auxquels je suis confronté pour mon appli tâche de
fond sur le serveur :
* fuite mémoire régulière et progressive.
Pour l'instant je n'ai pas cerné précisément la ou les fonctions WD qui
posent problème (il y avait eu la fonction fListeFichier avant la
version 206g mais le problème a été résolu).
Avec la 206g, au stade où j'en suis, je crois que HAjoute() pose un
réel problème de libération de mémoire (dans certains cas que je dois
encore déterminer).
Mon appli utilise en continu les fonctions suivantes :
- base HF (pas encore eu le temps de sauter le pas...)
- fonctions FTP intégrés (très nombreux envois)
- lecture, écriture, copies, suppressions de fichiers ASCII (en grand
nombre)
- utilisation de vues déclarées en "sources de données" (et libérées en
fin de traitement)
- utilisation de zones mémoires
- des HAjoute, HModifie mais aucun HSupprime
- une classe pour traçabilité dans des fichiers textes et un timer pour
détecter le changement de jour
J'ai externalisé dans un autre EXE (lancé quotidiennement) ma gestion
d'archivage : pour certains fichiers très utilisés, je créé des alias
mensuels, je copie les enregistrements du fichier actif (selon des
critères de date) vers l'alias et je supprime ensuite l'enregistrement
actif.
Le blocage+réindexation a l'air également de bouffer de la mémoire sans
la libérer, je vais bientôt l'externaliser également.
Cela ne va malheureusement pas résoudre tous mes soucis de fuite
mémoire...je cherche encore.
La prochaine étape est de passer l'application en service pour voir si
le problème ne vient pas des ressources graphiques de mon application
(une fenêtre simple avec un bouton et un champ texte qui change de
couleur lorsque des tâches sont actives, utilisation de ma classe
cSystray pour l'iconisation).
* J'ai tenté de mettre les principales tâches dans des threads
indépendants mais j'ai vite abandonné en constatant de nombreux
problèmes avec un serveur Xeon Hyperthreadé sous Windows Serveur 2003
(erreurs fatales non catchées par EXCEPTION) alors que l'appli marchait
correctement sous une station W2000 ou XP avec un processeur "normal".
Je n'ai pas voulu aller plus loin et suis revenu à une boucle sans fin
et séquentielle (les tâches sont lancées l'un après l'autre).
Je crois que je vais en venir à utiliser finalement une 3ème appli qui
arretera et relancera chaque jour l'appli principale et l'appli de
maintenance...
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Je n'ai que cette solution qui ne me plait pas trop: -Créer une nouvelle appli d'"Admin" agissant sur les mémes données que mes apllis clients et dont l'unique fonction serait de lancer des taches automatiquement.
Bonjour,
C'est en plein dans l'actualité en ce qui me concerne. Voilà les problèmes auxquels je suis confronté pour mon appli tâche de fond sur le serveur :
* fuite mémoire régulière et progressive. Pour l'instant je n'ai pas cerné précisément la ou les fonctions WD qui posent problème (il y avait eu la fonction fListeFichier avant la version 206g mais le problème a été résolu). Avec la 206g, au stade où j'en suis, je crois que HAjoute() pose un réel problème de libération de mémoire (dans certains cas que je dois encore déterminer). Mon appli utilise en continu les fonctions suivantes : - base HF (pas encore eu le temps de sauter le pas...) - fonctions FTP intégrés (très nombreux envois) - lecture, écriture, copies, suppressions de fichiers ASCII (en grand nombre) - utilisation de vues déclarées en "sources de données" (et libérées en fin de traitement) - utilisation de zones mémoires - des HAjoute, HModifie mais aucun HSupprime - une classe pour traçabilité dans des fichiers textes et un timer pour détecter le changement de jour J'ai externalisé dans un autre EXE (lancé quotidiennement) ma gestion d'archivage : pour certains fichiers très utilisés, je créé des alias mensuels, je copie les enregistrements du fichier actif (selon des critères de date) vers l'alias et je supprime ensuite l'enregistrement actif. Le blocage+réindexation a l'air également de bouffer de la mémoire sans la libérer, je vais bientôt l'externaliser également. Cela ne va malheureusement pas résoudre tous mes soucis de fuite mémoire...je cherche encore. La prochaine étape est de passer l'application en service pour voir si le problème ne vient pas des ressources graphiques de mon application (une fenêtre simple avec un bouton et un champ texte qui change de couleur lorsque des tâches sont actives, utilisation de ma classe cSystray pour l'iconisation).
* J'ai tenté de mettre les principales tâches dans des threads indépendants mais j'ai vite abandonné en constatant de nombreux problèmes avec un serveur Xeon Hyperthreadé sous Windows Serveur 2003 (erreurs fatales non catchées par EXCEPTION) alors que l'appli marchait correctement sous une station W2000 ou XP avec un processeur "normal". Je n'ai pas voulu aller plus loin et suis revenu à une boucle sans fin et séquentielle (les tâches sont lancées l'un après l'autre).
Je crois que je vais en venir à utiliser finalement une 3ème appli qui arretera et relancera chaque jour l'appli principale et l'appli de maintenance...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
stanislas
> Je crois que je vais en venir à utiliser finalement une 3ème appli qui arretera et relancera chaque jour l'appli principale et l'appli de maintenance...
Sans aller jusque à la 4eme appli pour s'occuper de la 3eme je pense qu'il y a probablement une solution du coté des services windows. Le gestionaire de tache de windows est peut être aussi à exploiter. Une dernière idée, si ta seconde appli faisait redémarer le serveur de façon quotidienne, c'est un peu bourrin mais souvent c'est ce qui marche le mieux.
En tous cas merci pour tous ces détails, ça me permet de prendre un petit peu d'avance sur les problèmes que je vais rencontrer...
Pour en revenir au gestionaire de tache je crois qu'il y un exemple windev à ce sujet, je regarde cela.
Stan
> Je crois que je vais en venir à utiliser finalement une 3ème appli qui
arretera et relancera chaque jour l'appli principale et l'appli de
maintenance...
Sans aller jusque à la 4eme appli pour s'occuper de la 3eme je pense
qu'il y a probablement une solution du coté des services windows.
Le gestionaire de tache de windows est peut être aussi à exploiter.
Une dernière idée, si ta seconde appli faisait redémarer le serveur de
façon quotidienne, c'est un peu bourrin mais souvent c'est ce qui
marche le mieux.
En tous cas merci pour tous ces détails, ça me permet de prendre un
petit peu d'avance sur les problèmes que je vais rencontrer...
Pour en revenir au gestionaire de tache je crois qu'il y un exemple
windev à ce sujet, je regarde cela.
> Je crois que je vais en venir à utiliser finalement une 3ème appli qui arretera et relancera chaque jour l'appli principale et l'appli de maintenance...
Sans aller jusque à la 4eme appli pour s'occuper de la 3eme je pense qu'il y a probablement une solution du coté des services windows. Le gestionaire de tache de windows est peut être aussi à exploiter. Une dernière idée, si ta seconde appli faisait redémarer le serveur de façon quotidienne, c'est un peu bourrin mais souvent c'est ce qui marche le mieux.
En tous cas merci pour tous ces détails, ça me permet de prendre un petit peu d'avance sur les problèmes que je vais rencontrer...
Pour en revenir au gestionaire de tache je crois qu'il y un exemple windev à ce sujet, je regarde cela.
