Pour connaître les machines connectées sur la base d'une application Réseau,
nous utilisons la méthode suivante.
- Ouverture du Projet : Création d'un fichier texte sur le répertoire
partagé des données avec le nom de machine et user :
r_log=fouvre(CheminBase+"\Log\"+utilisateur+".txt",focreation)
si r_log=-1 alors
info("Erreur de Login")
sinon
// on écrit la date et heure de login
rt=fecrit(r_log,dateverschaine(datesys())+rc)
rt=fecrit(r_log,gauche(heureverschaine(heuresys()),5)+rc)
rt=fecrit(r_log,machine) // Nom de l'utilisateur
fin
- Fermeture du Projet :
Destruction du fichier texte
- Pour lister les machines connectées :
o Tentative de destruction de tous les fichiers textes ( en cas de sortie
violente de l'application)
o Ceux que l'on ne peut pas détruire sont donc des machines avec le logiciel
actif.
Cette procédure fonction très bien depuis des années sous 98,Me Wind 200
Pro.
Sous l'explorateur, la tentative de destruction de ce fichier texte génère
une erreur de violation ( normal le fichier est ouvert par un autre poste)
Par contre Sous Windows XP, on peut détruire par l'explorateur le fichier de
log d'une autre machine sans message d'erreur. Le fait de faire F5 (
actualiser) remontre ce fichier texte de LOG.
De plus sous l'application, la procédure de tentative de destruction de ces
fichiers texte ( Fsupprime ) ne fonctionne plus ( renvoie 0 comme si ok pour
la destruction )
Cette procédure nous sert à savoir si des machines sont connéctées avant
synchro des bases. D'ou problèmes..
Avez vous constaté ce phénomène. Et comment y remédier
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en WD7/8).
De plus sous l'application, la procédure de tentative de destruction de ces fichiers texte ( Fsupprime ) ne fonctionne plus ( renvoie 0 comme si ok pour la destruction )
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 : WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur) WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1 (vrai) si tout est OK)
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
SebNews a exprimé avec précision :
Pour connaître les machines connectées sur la base d'une application Réseau,
nous utilisons la méthode suivante.
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en
WD7/8).
De plus sous l'application, la procédure de tentative de destruction de ces
fichiers texte ( Fsupprime ) ne fonctionne plus ( renvoie 0 comme si ok pour
la destruction )
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 :
WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur)
WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1
(vrai) si tout est OK)
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en WD7/8).
De plus sous l'application, la procédure de tentative de destruction de ces fichiers texte ( Fsupprime ) ne fonctionne plus ( renvoie 0 comme si ok pour la destruction )
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 : WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur) WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1 (vrai) si tout est OK)
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
SebNews
Bonjour Romain
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en WD7/8).
c'est une ancien application sous 5.5B
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 : WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur) WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1 (vrai) si tout est OK)
Le problème vient ici d'un changement de comportement selon le système. Fsupprime me renvoie 0 ( OS XP en WD en 5.5b) alors qu'il ne devrait pas pouvoir détruire ce fichier ( en cours sur un autre poste)
Mais cela ne vient pas de la fonction Fsupprime. Depuis un Windows XP, avec l'explorateur, j'arrive à détruire le fichier texte de LOG créé ( et ouvert ) par un autre poste sur le partage sans message d'erreur. En faisant un F5, ce fichier texte est de nouveau présent sous l'explorateur.
Je pense que c'est plutôt du au système
Quelqu'un peut il faire le Test ? ( 5.5 B) je n'arrive pas à comprendre le phénomène
Merci Sébastien
Bonjour Romain
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en
WD7/8).
c'est une ancien application sous 5.5B
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 :
WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur)
WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1
(vrai) si tout est OK)
Le problème vient ici d'un changement de comportement
selon le système.
Fsupprime me renvoie 0 ( OS XP en WD en 5.5b) alors qu'il ne devrait
pas pouvoir détruire ce fichier ( en cours sur un autre poste)
Mais cela ne vient pas de la fonction Fsupprime.
Depuis un Windows XP, avec l'explorateur, j'arrive à détruire le
fichier texte de LOG créé ( et ouvert ) par un autre poste sur le partage
sans message d'erreur. En faisant un F5, ce fichier texte est de nouveau
présent sous l'explorateur.
Je pense que c'est plutôt du au système
Quelqu'un peut il faire le Test ? ( 5.5 B)
je n'arrive pas à comprendre le phénomène
Essaye plutôt avec foCreation+FoBloqueEcriture (nouveau paramètre en WD7/8).
c'est une ancien application sous 5.5B
Attention, le résultat de fsupprime en WD7/8 diffère de celui de WD55 : WD55 : fsupprime renvoie 0 si tout est OK (-1 en cas d'erreur) WD7/8 : fsupprime renvoie 0 (false) si une erreur est survenue (1 (vrai) si tout est OK)
Le problème vient ici d'un changement de comportement selon le système. Fsupprime me renvoie 0 ( OS XP en WD en 5.5b) alors qu'il ne devrait pas pouvoir détruire ce fichier ( en cours sur un autre poste)
Mais cela ne vient pas de la fonction Fsupprime. Depuis un Windows XP, avec l'explorateur, j'arrive à détruire le fichier texte de LOG créé ( et ouvert ) par un autre poste sur le partage sans message d'erreur. En faisant un F5, ce fichier texte est de nouveau présent sous l'explorateur.
Je pense que c'est plutôt du au système
Quelqu'un peut il faire le Test ? ( 5.5 B) je n'arrive pas à comprendre le phénomène
Merci Sébastien
laurent
bonjour
pour gérer les postes ouverts sur un réseau j'ai utilisé une suggestion présentée dans une ancienne LST Elle consiste à ajouter un fichier HF à la base partagée qui contient les zones suivantes : NUM_SESSION numéro unique de session NOM_LOGIN renseigné avec ReseauUtilisateur() NOM_POSTE renseigné avec le nom de la station (enregistré dans la base d registes) NOM_LOGICIEL et éventuellement DATE et HEURE de connexion
à chaque connexion on essaie de bloquer toutes les fiches du fichier hnombreessai=1 // fait une seule tentative de verrouillage de fiche au lieu de 5 si Hlit(fichier_session,hnumenr,hbloqueecriture) hsupprime(fichier_session) // sortie violente de l'utilisateur fin
On mémorise dans une variable globale un n° de session unique
puis on renseigne les zones HF et on ajoute une fiche Hajoute(Fichier_session) et on bloque la fiche Hlit(fichier_session,hnumenr(),hbloqueecriture)
En fin de programme on relit la fiche avec le n° de session enregistré en varible globale et on la débloque puis on l'efface
Cette technique permet de savoir combien de gens sont connectés (pour ceux qui veulent limiter le nombre de connexions simultanées), qui est connecté et ou ils sont connectés pour éventuellement envoyer un message de "logout"
par ailleurs cela permet de lancer un batch de sauvegarde ou réindexation ou traitement à risque en s'assurant que personne n'est connecté à la base. J'ai ajouté une fonction de verrouillage de la base en ajoutant dans un fichier ini un paramètre VERROU=oui ou non qui autorise ou refuse l'utilisation du logiciel pendant les batches sensibles.
Cette technique est utilisée depuis la version 4 sous windows 95 et fonctionne toujours en version 8 sour w95 + w98 + wXP salutations
bonjour
pour gérer les postes ouverts sur un réseau j'ai utilisé une suggestion
présentée dans une ancienne LST
Elle consiste à ajouter un fichier HF à la base partagée qui contient les
zones suivantes :
NUM_SESSION numéro unique de session
NOM_LOGIN renseigné avec ReseauUtilisateur()
NOM_POSTE renseigné avec le nom de la station (enregistré dans la
base d registes)
NOM_LOGICIEL
et éventuellement DATE et HEURE de connexion
à chaque connexion on essaie de bloquer toutes les fiches du fichier
hnombreessai=1 // fait une seule tentative de verrouillage de fiche
au lieu de 5
si Hlit(fichier_session,hnumenr,hbloqueecriture)
hsupprime(fichier_session) // sortie violente de l'utilisateur
fin
On mémorise dans une variable globale un n° de session unique
puis on renseigne les zones HF et on ajoute une fiche
Hajoute(Fichier_session)
et on bloque la fiche Hlit(fichier_session,hnumenr(),hbloqueecriture)
En fin de programme on relit la fiche avec le n° de session enregistré en
varible globale et on la débloque puis on l'efface
Cette technique permet de savoir combien de gens sont connectés (pour ceux
qui veulent limiter le nombre de connexions simultanées), qui est connecté
et ou ils sont connectés pour éventuellement envoyer un message de "logout"
par ailleurs cela permet de lancer un batch de sauvegarde ou réindexation ou
traitement à risque en s'assurant que personne n'est connecté à la base.
J'ai ajouté une fonction de verrouillage de la base en ajoutant dans un
fichier ini un paramètre VERROU=oui ou non qui autorise ou refuse
l'utilisation du logiciel pendant les batches sensibles.
Cette technique est utilisée depuis la version 4 sous windows 95 et
fonctionne toujours en version 8 sour w95 + w98 + wXP
salutations
pour gérer les postes ouverts sur un réseau j'ai utilisé une suggestion présentée dans une ancienne LST Elle consiste à ajouter un fichier HF à la base partagée qui contient les zones suivantes : NUM_SESSION numéro unique de session NOM_LOGIN renseigné avec ReseauUtilisateur() NOM_POSTE renseigné avec le nom de la station (enregistré dans la base d registes) NOM_LOGICIEL et éventuellement DATE et HEURE de connexion
à chaque connexion on essaie de bloquer toutes les fiches du fichier hnombreessai=1 // fait une seule tentative de verrouillage de fiche au lieu de 5 si Hlit(fichier_session,hnumenr,hbloqueecriture) hsupprime(fichier_session) // sortie violente de l'utilisateur fin
On mémorise dans une variable globale un n° de session unique
puis on renseigne les zones HF et on ajoute une fiche Hajoute(Fichier_session) et on bloque la fiche Hlit(fichier_session,hnumenr(),hbloqueecriture)
En fin de programme on relit la fiche avec le n° de session enregistré en varible globale et on la débloque puis on l'efface
Cette technique permet de savoir combien de gens sont connectés (pour ceux qui veulent limiter le nombre de connexions simultanées), qui est connecté et ou ils sont connectés pour éventuellement envoyer un message de "logout"
par ailleurs cela permet de lancer un batch de sauvegarde ou réindexation ou traitement à risque en s'assurant que personne n'est connecté à la base. J'ai ajouté une fonction de verrouillage de la base en ajoutant dans un fichier ini un paramètre VERROU=oui ou non qui autorise ou refuse l'utilisation du logiciel pendant les batches sensibles.
Cette technique est utilisée depuis la version 4 sous windows 95 et fonctionne toujours en version 8 sour w95 + w98 + wXP salutations
SebNews
Bonjour, merci pour cette réponse complète. En efffet le but est de gérer les sorties violentes du logiciel.
La solution des fichiers texte fonctionne aussi très bien sauf avec Windows XP. Si je ne trouve pas la raison, je vais je pense m'inspirer de cette solution.
Merci Sébastien
Bonjour,
merci pour cette réponse complète.
En efffet le but est de gérer les sorties violentes du logiciel.
La solution des fichiers texte fonctionne aussi très bien
sauf avec Windows XP.
Si je ne trouve pas la raison, je vais je pense m'inspirer
de cette solution.
Bonjour, merci pour cette réponse complète. En efffet le but est de gérer les sorties violentes du logiciel.
La solution des fichiers texte fonctionne aussi très bien sauf avec Windows XP. Si je ne trouve pas la raison, je vais je pense m'inspirer de cette solution.
