|
| Inicio → WINDEV 2025 → Erreur d'écriture dans le fichier des utilisateurs connectés à l'application |
| Erreur d'écriture dans le fichier des utilisateurs connectés à l'application |
| Iniciado por To Ma5, 26,dic. 2019 15:21 - 11 respuestas |
| |
| | | |
|
| |
Miembro registrado
28 mensajes |
|
| Publicado el 26,diciembre 2019 - 15:21 |
Bonjour,
Je cale sur un problème chez un client.
Lorsqu'on lance notre application sur son poste (il s'agit d'une install réseau) il y a le message d'erreur suivant :
Erreur d'écriture dans le fichier des utilisateurs connectés à l'application , puis le chemin réseau (qui est bon).
J'ai tenté :
- De forcer les droits au niveau du serveur pour le dossier en question
- Reinstaller a la version client
- Supprimer toute reference de WDupdate.net sur le poste client.
A savoir également que :
- Le programme fonctionnait bien avant sur le poste (le PC aurait planté et depuis ca ne fonctionne plus)
- Il y a d'autres utilisateurs et pour eux ca fonctionne bien (ils se connectent de la même maniere au serveur, avec le meme user)
Bref quelqu'un peut il m'en dire plus par rapport à ce message d'erreur, si vous avez déjà rencontré ce problème. Mes recherches sur le net n'ont pour l'instant rien donné de plus.
Merci d'avance
Thomas
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
28 mensajes |
|
| Publicado el 27,diciembre 2019 - 09:18 |
Bonjour,
Aujourd'hui le problème a lieu chez un autre client.....
Je soupconne une mise à jour windows ou qq chose comme ca qui créerait ce problème car ce n'est jamais arrivé avant..
Personne n'a une piste ?
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,diciembre 2019 - 06:19 |
Tu ne le précise pas, mais je crois lire entre les lignes que tu travaille en HF classique à travers un réseau, ce qui est à proscirre depuis windows VISTA, du fait du changement de gestion des oplocks qui est entré dans windows à ce moment la...
Si c'est bien le cas, il y a PLEIN de posts à ce sujet ici, et la conclusion est que si tu veux une solution perenne, il te faut passer en HF Client Serveur, parceque même si tu paramèrte à la main exactement comme il faut ton système d'oplock, n'importe quelle MAJ de windows, aussi bien sur les clients que sur le serveur peut recréer le problème. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
28 mensajes |
|
| Publicado el 30,diciembre 2019 - 10:00 |
bonjour Argus,
Effectivement il s'agit bien d'un HF classique par réseau. Je sais bien que ce n'est pas une pratique à mettre en place mais le logiciel est ainsi fait et il y a beaucoup de clients je ne peux pas tous les passer en HF C/S en urgence.
En attendant (et meme si je sais que ce n'est pas un solution sur le long terme, et j'entend bien les risques que ca implique que ce soit en terme de sécurité que d'exploitation) en réactivant SMB v1 sur le poste client j'ai réussi à faire repartir le programme.
Merci pour ton aide.
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,enero 2020 - 16:19 |
Bonjour,
J'ai le même problème aujourd'hui pour la première fois mais le passage à la connexion à la base en client serveur ne résout rien.
As-tu trouvé une solution ? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
28 mensajes |
|
| Publicado el 08,enero 2020 - 17:21 |
Ca fait un moment que ca me pose des soucis. aujourd'hui un des clients à refait une "fresh install" de windows sur une VM et ca fonctionnait. A voir si ca dure sur le long terme car j'ai réussi à le débloquer mais à chaque redémarrage de la machine ca ne refonctionnait plus.
J'ai testé de désactiver les OPLOCKS au niveau client et serveur et ca ne fonctionne pas non plus.
Pour info voici la réponse de Support pc soft :
"Suite à une mise à jour ou en utilisation d'une version récente de Windows, Microsoft peut imposer d'avoir un client réseau au même niveau sur les ressources partagées des serveurs. Il est probable que l'application de tous les Windows update adaptés à votre serveur supprime le défaut.
Par exemple, d'après les informations que nous avons à ce jour, depuis la mise à jour de Windows 10 "April Update" (1803), Windows bloque les accès réseau à un exécutable qui est lancé depuis un partage en Samba version 1 (SMBv1). Pour résoudre ce problème il faut mettre le partage réseau en Samba version 2 (SMBv2) ou version 3 (SMBv3).
Nous avons déjà également eu un retour d'un cas où l'erreur provenait du fait que le nom du serveur était en majuscule , pour résoudre il a fallu passer le nom en minuscule ou mettre l'adresse IP (IPV4)."
Pour revenir sur la réponse apportée par Argus, effectivement l'installation du client/serveur ne résoudra rien dans le cas présent dans la mesure où le fichier en question est lié à une installation "liveupdate" et donc les fichiers sont forcément gérés de cette manière par l'installeur.
Si je trouve une solution pérenne, j'alimenterais ce post.
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,enero 2020 - 14:55 |
Merci  , je vais essayer de me débrouiller avec ça ! |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
7 mensajes |
|
| Publicado el 13,enero 2020 - 17:54 |
Bonjour,
Nous avons également remarqué un problème identique sur un serveur 2012 R2. Il semblerait que cela soit effectivement lié à une MAJ, peut être la MAJ du 23/12/19 sur le serveur.
La base utilisée est une base HFSQL C/S hébergée sur le CLOUD, mais le pb survient bien avant la connexion, donc pas liè à la gestion des datas.
Pour palier TEMPORAIREMENT le pb, nous avons renommer le fichier WDUpate.net comme cela le control de version ne se fait pas et l'appli s’exécute.
Il y a à priori la solution de réactiver la version 1 de SMB. J'aimerai tester cette solution mais comment fait on pour la réactiver ?
Merci |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
28 mensajes |
|
| Publicado el 14,enero 2020 - 09:09 |
Bonjour olivier,
C'set effectivement à cette date que les soucis ont commencé pour ma part. Cependant j'ai également rencontré ce problème chez des clients qui utilisent un NAS et qui ne sont donc pas sous windows server. Ceci dit la mise à jour windows 1909 concerne les versions server et client..
Pour l'activation réactivation de SMB v1 voir ici :
https://www.malekal.com/activer-desactiver-smb-windows/…
Cependant dès le redémarrage ca ne fonctionnait plus. Je ne pense pas que ce soit vraiment une solution fiable d'autant que SMB v1 comporte des failles de sécurité importante qui laisse notamment la porte ouverte à des cryptlockers ...
Je vais essayer de renommer le WDupdate.net . On perd l'avantage de la mise à jour réseau mais toujours mieux que rien.
Merci pour ta contribution.
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
7 mensajes |
|
| Publicado el 05,febrero 2020 - 18:19 |
Bonjour,
Je reviens sur ce sujet pour vous informer que dans mon cas le pb provenait d'un bug de Kaspersky (répertorié sous le n°3968077).
Il n'est pas résolu à ce jour, mais le sera probablement lors de la sortie de la version 21.
Bon Dev à tous |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
28 mensajes |
|
| Publicado el 06,febrero 2020 - 09:43 |
Merci pour ces précisions, de mon coté suite à la réinstallation de mon poste ces jours ci j'ai également le problème....
A savoir que je suis aussi sous kaspersky.
--
Tom A. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
66 mensajes |
|
| Publicado el 28,julio 2020 - 10:07 |
Bonjour à tous
attention, la mise à jour Window 10 - 2004 pose des problèmes avec la fonction RéseauConnecte() sur des serveurs en SMB1 avec accès anonyme
(erreur 10)
le fait d'activer le SMB1 client dans W10 (comme W10-1903) ne change rien, j'ai toujours l'erreur 10 malgré que les lecteurs réseau soient
visibles et explorables,
Donc RéseauConnecte() , dans ce cas, ne permet plus la connexion d'un lecteur réseau distant; je n'ai rien trouvé comme solution de la part de Microsoft malgré la demande de beaucoup de gens sur les forums
la seule solution est de désactivé , l'appel de cette fonction et passer par un Bat avec Net Use 
Bon courage à tous |
| |
| |
| | | |
|
| | | | |
| | |
|